How To Secure Login Credentials for Ajax

Cross-Posted From : CodeOnFire.cThru.biz

Many JavaScript and other clients that make use of REST or other web services have to use authentication credentials to allow the end user access to those services.

There are several ways to get the credentials to the server. One popular method is using HTTP1.1 Auth, either digest or basic. The problem with this method is that it doesn’t hide your credentials from the world. Anybody listening in on your web traffic is essentially able to get your credentials from the headers.

Another method, probably more readily used by the majority, is to include login credentials in the POST or GET calls being made to web services. And that is just as exposed.

http://mywebserver.com/mywebservice/?user=admin&pass=1234
does not make for very high transport security.

SSL is really the only way to be sure that your credentials remain hidden from the rest of the world.

Server Generated Tokens for Obscuring Login Credentials

I have taken up a different tactic. It runs the following course:

The client requests a random token from the server to use during it’s session.
Once it receives the token the client concatenates the token to the end of the password, and then does an MD5 hash on the whole thing.
When credentials are needed by the server, the client then passes user=’username’&passhash=[md5(password+token)]
The server compares this with the same process on it’s end. If the two hashes match, then the passwords used in those hashes has to be the same as well.

The beauty of this method is that although it is a 100% reliable method for correctly identifying the correct credentials, it is also impossible to reverse the process and get the password back.

Taking things one step Further

The initial step for me was to use [md5(password+token)]. I have now updated it use a variety of information I would like to hide:
[md5(username+password+my_ip+token)] which has some built in cross-site scripting obfuscation built in.

A devious and very zealous hacker can still hijack your session with some effort. And you can make sure it is not worth his/her while by regularly changing the token for the current session.

KnowledgeTree JavaScript API

As a developer on KnowledgeTree I am currently working on set of JavaScript libraries that will expose server functionality via an API. A core component of KnowledgeTree is it’s strict security. The method mentioned above (or a variant of it) is in the process of being implemented for KnowledgeTree jAPI.

Onwards and Upwards!

Follow me on Twitter: @MarkH_KT

Plain Text of Passwords Stored in DB

August 18, 2009 - 4:13pm — Don Albrecht (not verified)

The problem with this solution as I see it, is that it requires the server to be able to recover the password in plain text from somewhere. Since most users recycle passwords as a natural coping strategy, this leads to a possible vulnerability of sensitive personal information being stolen from one venue and used to exploit a second venue.

Plain Text Passwords are not Stored in DB

August 19, 2009 - 9:07am — Mark Holtzhausen

Hi Don,

For the sake of brevity and conceptual clarity, I sometimes omit certain steps on my blogs that are implemented in the actual KnowledgeTree ClientTools authentication layer.

The password of a user is not stored in plaintext anywhere in the system. Upon registration it is immediately MD5'd and stored as a hash.

From the client side, it is easy to work within these parameters. Since the MD5 of the password will always be the same, the client side first does an MD5 of the password entered, then takes that hash, adds the token hash and sends the hash of the entire thing back to the server for credential verification.

So a more accurate url implementation can be represented like this:

http://your_knowledgetree_server/clienttools_webservices_path/?user=’username’&passhash=[md5(md5(password)+token))]

The server then compares the passhash by appending the token to the stored HASH of the originally entered password, and applying MD5 to that string.

To reiterate: KnowledgeTree never stores plain text passwords anywhere in the system.

Greetings,
Mark Holtzhausen

we don't need plain text password

October 5, 2009 - 11:34am — visitor

1. take the md5(password) hash ( from db or sniff it while user changes his password)
2. calculate response as md5 ( md5(password) + what ever tokens) and send it to the server

conclusion:
if we have md5(password) hash, we don't need plain text password to login

Jerry

Even hashed passwords not really secure..

January 21, 2010 - 9:53am — Mark Holtzhausen

Hi Jerry,
I'm not sure I exactly follow your argument. Here's my 2c anyway:

It sounds like you are describing the same method as I did earlier. Plain text passwords are sniff-able over non SSL connections, and that makes the user vulnerable. If you hash the password before storing it in the database, it really isn't that much more secure, if you use the conventional approach: You can still sniff the hash over non secure connections, and even if you don't know the original password, you can log into the account using the hash.

The main reason why we're using tokens is because md5 is a uni-directional, lossy hash. By combining the token and the hashed password and then hashing the whole thing, you generate a key that will unlock the account without revealing ANY information that can be usefully sniffed.

In the meantime, I have implemented an even more robust and secure transport protocol, which I will blog about soon.

Regards,

follow me on Twitter