On "Passwordless" Authentication: A New Paradigm

Tuesday, January 04, 2011

Gurudatt Shenoy


"Passwordless" Authentication: A new paradigm in enforcing authentication and encryption...

The previous year has gone by and it reflected on the vulnerabilities associated with passwords and other security breaches.

Notably, this involved the Gawker Media password dump and the WikiLeaks data theft.

And that made me reflect on if we can have a world without passwords, and yet still secure identity and information.

I ventured into this minefield exactly two years back, and invented an innovative solution that I thought could change the way people are identified online and their information secured.

The concept can be simply described as follows:

1. Do not store the password or key on the server or the client device.

2. Do not to prompt the user to define or enter passwords.

3. Encrypt information before storing it on the server by using a seed that is not stored anywhere, but is generated in real time.

Instead of storing the password on the server, one can encrypt and store the user identity or username using a real time generated password, either by using a hashing algorithm or a device-locked password generator.

The password itself need not be stored on the server, as can be seen from the following diagrams:

Password Less Registration 


Once the user is registered, he or she can be authenticated as follows:


User Authentication without passwords

If websites or online services employed a "passwordless" authentication, it will help mitigate many of the current vulnerabilities, such as the one experienced by Gawker Media.

Even if the server data is hacked, it does not contain the password, and without it the encrypted information would be meaningless.

Possibly Related Articles:
Network Access Control
Encryption Passwords Authentication Access Control Innovation
Post Rating I Like this!
Shane McCallum Interesting post but how does this work if the clients computer dies or he/she wants access from a public computer?
Gurudatt Shenoy Shane,

I have developed solutions for the issue you mentioned. It is very simple.

The service provider has to create an identity server that registers multiple devices of the user for accessing the same account.

I have created such a server and using it for my solutions such as mycloudkey.com and trustpad.com

There is another solution and that is to register a portable device such as a USB drive or a cellphone and connect it to a public terminal to access the account.

The third option is to send an encrypted master key to the users email id which can be used to register a new device in case the original device stops working or is misplaced...or dies in your words

Such a solution is hosted on 0pass.com

At the moment, I cannot reveal the algorithm as I plan to file a patent on the same.
Gurudatt Shenoy The following diagram explains the concept behind MyCloudKey

Ashutosh Agrawal what if i clone the device of particular user...
Gurudatt Shenoy How easy it will be to clone every user device know his or her username as compared to guessing a password!

The user can be also given an option of adding voice recognition or fingerprint other biometric recognition to provide additional security or provide the option of selecting from a range of devices or combination.

So you will also need to know which device or combination of devices to clone.

Ashutosh Agrawal i have one more doubt...
suppose i have the user id of target user 'U' and let 'x' be the unique password from signature of device.
And as the password data are unsecure so would be the encrypted user id's let it be 'eu' now i have the algorthim for encrypting using function f
then f(U,x) = eu;
can't i find the x from this relation ... ?
Gurudatt Shenoy You are assuming the password data is unsecure...The password is not stored anywhere for your information so the hacker has no way of arriving at the password without gaining access to the device. So it is next to impossible to arrive at x.

So even if you have eu, without knowing the value of x, you cannot arrive at the value of U.

And by knowing just the value U and the value eu, you cannot arrive at the value of x because x is not encrypted but U.

So yes, if you can clone the device used by the user you can anyways get access to the account if you also know the value of U as that will generate the value eu.

The diagram and representation made here is a basic concept to an alternative authentication model from the current username/password combination where the username is stored in text form and only the password is encrypted using a common seed for all users.

I have developed more complicated algorithm that provides a more tight secured model compared to what is represented in the above diagram.

Ofcourse, I am not about to disclose that algorithm here as it is still proprietary and awaiting a patent filing.

Gurudatt Shenoy So,

eu = encrypt(U,x)

where eu = encrypted userid, U = username, x = password (device id)

if you know the value of U and have access to the value eu you cannot arrive the value of x by using....

x = decrypt(eu,U)

Decrypt can only work as follows as per the encrypt/decrypt algorithm

U = decrypt(eu,x)

Hope you got the math...

Steve Jackson Gurudatt, his is an interesting idea, but I'm not sure I have fully understood it so I have the following questions:
1. Is access restricted so that it is only from specific devices?
2. How do you protect against a registed device being spoofed?
3. Is this a simplified version of 2-factor authentication (e.g. RSA token, Cryptocard)?

Gurudatt Shenoy 1. Is access restricted so that it is only from specific devices?
Yes. Either the user can select the device of his choice or the website can
offer the user a particular device to use with their login.

2. How do you protect against a registed device being spoofed?
The signature of the registered device is not required to be stored on the authenticating
server for authentication. The authentication algorithm requires both the device id
as well as user id / pin entered by the user to successfully authenticate the user.

If either one is not available the authentication will fail.

The device id can be prevented from being spoofed by using programming code that does
not transmit the device id from client to server and if the code is hosted on
a different server, the authenticaton code will not work.

So basically by writing a code that verifies all the following aspects it is possible to
protect generating the authenticating id.

a. Do not store device ID on device or server.
b. Do not transmit the device id from client to server.
c. Do not directly use the device id for authentication. Enforce authentication
dependent on various other factors such as the domain from which the code is executed,
the user id entered by the user, a seed unique to the application, etc.

3. Is this a simplified version of 2-factor authentication (e.g. RSA token, Cryptocard)?

RSA Tokens use a prorietary device or use a onetime password generation method to
enforce two factor authentication.

There are many other solutions out there which offer two factor or multi-factor
authenticaton such as yubikey, ironkey, etc.

However, this solution is unique as it allows the user to select a device he or she
already owns and use it for all the websites. This means the user does not have to
own a different device to access each individual application. He or she can use their
cell phone as a security token.

The other difference is information stored on the server does not include the authentication
key which means even if the server database is hacked, the hacker will find it really
touch to decrypt individual records as each of the records are encrypted using a unique
set of keys based on the user device and other factors.

So anyone who develops a solution using this concept can provide a low cost and highly
secure authentication product.
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.