Password Hashing

A variety of software such as the Unix operating system make use of password hashing
to easily verify and authenticate users that have had previous interaction with the
software.
A passwords hash key is usually stored in a device instead of the password itself.
When a user tries to authenticate, the hash key generated from their password is often
sent to the requester and matched against a previously stored hash.
This method could possibly be applied to the signet ring as well.
An individual could generate their own password that could be an arbitrary number of
bits wide and then pass this through a hash function.
The resulting hash key could be passed to the device and stored there for all future
authentications.
Providing password hashing would significantly lower the number of bits that would
need to be transmitted.
One-Way Password
The easiest and simplest method to implement
Requires only decoding and processing on the phone end
Transmits n bits to the phones screen where n is the number of bits in the users
password
The traditional ASCII table requires 8 bits to represent all its values
For the signet ring to match the capability of standard password strength; a password 6
characters long would need to be stored and transmitted
This operation would require at least 48 bits to be transmitted to the phone application
To achieve good responsiveness and authentication, a bit rate of 50 bits/sec would most
likely be needed
Although the users password does not need to be stored on the signet ring as an alpha-
numeric combination; the information entropy would still be the same for a generated
bit pattern
The application would only need to decode and authenticate the password locally a
single time
Challenge / Response Authentication Mechanism (CRAM)
This method would be best to eliminate a possible middleman intercepting passwords
transmitted to the screen
The device should contain the hash key or full password of the user intending to be
authenticated.
The signet ring will signal to the device that it wants to authenticate a user.
The device would then transmit a short challenge value to the signet ring
The signet ring would then compute a response based on a previously defined hashing
function known by both parties
The signet ring would generate a unique hashing value using both the password and
challenge value and then transmit this value back to the device
The device simultaneously computes the correct hashing value based on the already
cached password and the challenge value, which it compares against the user response
If the two values match, then the user will be authenticated.
Because this method utilizes a hashing function to compute a transmitted value, the
actual password is never vulnerable.
An additional secret value could be provided to both the device and signet ring to
increase security. This way if a malicious user deduced the hashing function, they could
still not derive the original password without the secret value.
Because this method requires two way communication, a hardware receiver would need
to be implemented onto the signet ring.
Although the process would take a bit more processing time to complete; the required
number of bits and bit rate would not really change from that used by the basic one-way
password.
Two-Factor Authentication
This type of authentication would be ideal for situations in which the security of the
data being accesses was very high
This type of authentication would require the users password to be transmitted to the
phone
The application would have to decode and authenticate the user with the given
password
If the authentication was successful, then the user would be prompted for a second
form of authentication
This second form would have to be some form of user interaction, that does not require
interaction with the signet ring
The user could be prompted for a short pin number
The application could also make use of similar authentication techniques native to
Android such as facial recognition, connecting a unique sequence of dots, an additional
typed password, or basic security question that ideally only a legitimate user could
answer
This form of authentication would only require the bit-rate of the one-way password,
but would also require additional time and resources to provide the second form of
authentication
RSA based authentication that utilize computationally difficult prime integer
factorization could also be used to increase security.
Also a two way challenge / response could be easily added in which both the user and
device authenticate each other
This method would allow the signet ring to authenticate the target device before
transmitting any sensitive data to eliminate malicious attempts on the device side.
Progressive Authentication
With this type of authentication the user, would have to provide increasingly more
complex or longer passwords when trying to access high security data or
applications
Authentication could be divided into levels of security
o The first level could be a very simple short passcode used for low security
applications such as unlocking the phone
o The second level would require a longer, more complex password to
authenticate the user for applications like online banking or accessing private
data files
The first level of authentication would require around 50 bits to be transmitted at
about 50 bits/sec (same as one-way password)
The second level of authentication would probably require around 2-3 times as
many bits as the one-way password (100-150 bits) to expand the total permutations
of possible passwords
While a quicker bit-rate would be ideal to handle the increased load of a longer
password; the user would be conscious of the fact that they are providing higher
level security and would probably not mind the extra transmitting delay
Other authentication techniques could be utilized instead of a longer password, such
as tracing a pattern with the ring while transmitting the password.
The x-y positions of the touch events could be used to match the rings path on the
screen against one already stored on the device.
However, methods like this would require the device to have previous interaction
with the user to allow extra authentication data to be stored locally.
This method would require the same amount of bits and bit-rate as the one-way
password.
The second level of authentication could make use of the challenge / response
mechanism to further authenticate a user
The following link, is the summary of a software project that implemented a
progressive authentication system on Android
http://css.csail.mit.edu/6.858/2013/projects/jtwarren-vkgdaddy-vedha-vvelaga.pdf
Continuous Authentication
This would be the case if two or more users were constantly contacting the device
touchscreen and needed to be identified separately
Because, it is not feasible to require users to constantly hold the ring against the screen
for every action to authenticate; the total number of bits to transmit must be very low
A possible scheme to identify multiple users on the same screen could involve an initial
authentication such as the one-way password
After the initial authentication, the device returns a user identifier to the signet ring.
This user identifier value that was 3 bits wide would allow for 8 unique simultaneous
users.
From this point on the signet ring would only transmit the short user identifier value to
the touchscreen, allowing the device to differentiate between users.
A bit rate of just 10bits/sec would probably be sufficient to simultaneously identify
unique users