Comments on: Secure Passwords sans SSL http://terrbear.org/?p=210 ruby! rails! kids! oh my! ... and other fun from terry heath Tue, 31 Aug 2010 17:32:13 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Caffeine Driven Development » Blog Archive » L33t Links #65 http://terrbear.org/?p=210&cpage=1#comment-858 Caffeine Driven Development » Blog Archive » L33t Links #65 Sun, 10 Jan 2010 20:02:03 +0000 http://terrbear.org/?p=210#comment-858 [...] Secure Passwords sans SSL [...] [...] Secure Passwords sans SSL [...]

]]> By: Can't you see the problem here ? http://terrbear.org/?p=210&cpage=1#comment-857 Can't you see the problem here ? Sun, 10 Jan 2010 10:44:37 +0000 http://terrbear.org/?p=210#comment-857 What happends if javascript is disabled/unavaillable ? Simple, not only you send the password in plaintext for anyone to see, but the authentication is rejected every time, so it's likely the user will try again (just in case it's password wasn't stolen already). Like Donald Parish suggested, just use HTTP Digest Authentication. It's the Standart Way That Works, and you can still use javascript to make it beautiful to your users if you want. But don't expect it to be as secure as SSL. SSL is SSL for a reason. What happends if javascript is disabled/unavaillable ?

Simple, not only you send the password in plaintext for anyone to see, but the authentication is rejected every time, so it’s likely the user will try again (just in case it’s password wasn’t stolen already).

Like Donald Parish suggested, just use HTTP Digest Authentication. It’s the Standart Way That Works, and you can still use javascript to make it beautiful to your users if you want.
But don’t expect it to be as secure as SSL. SSL is SSL for a reason.

]]> By: TempusFactor » Blog Archive » links for 2010-01-08 http://terrbear.org/?p=210&cpage=1#comment-854 TempusFactor » Blog Archive » links for 2010-01-08 Sat, 09 Jan 2010 00:13:28 +0000 http://terrbear.org/?p=210#comment-854 [...] Secure Passwords sans SSL @ terrbear.org (tags: javascript password security) [...] [...] Secure Passwords sans SSL @ terrbear.org (tags: javascript password security) [...]

]]> By: Alexey Borzenkov http://terrbear.org/?p=210&cpage=1#comment-853 Alexey Borzenkov Fri, 08 Jan 2010 18:02:23 +0000 http://terrbear.org/?p=210#comment-853 Oh, and one important note: you shouldn't use cookie session stores with non-SSL authentication. The problem is that man-in-the-middle can intercept cookie snapshots and reuse the same stamp/message again for authenticating a different browser. To be sure no one can 'rollback' session like that you must use database store. Oh, and one important note: you shouldn’t use cookie session stores with non-SSL authentication. The problem is that man-in-the-middle can intercept cookie snapshots and reuse the same stamp/message again for authenticating a different browser. To be sure no one can ‘rollback’ session like that you must use database store.

]]> By: Alexey Borzenkov http://terrbear.org/?p=210&cpage=1#comment-852 Alexey Borzenkov Fri, 08 Jan 2010 17:55:48 +0000 http://terrbear.org/?p=210#comment-852 @mike Why would you want a way to securely pass salt to clients? Salt is just an arbitrary random value, stored unencrypted in the database. There's no reason in treating salt as secret: it is not. @mike
Why would you want a way to securely pass salt to clients? Salt is just an arbitrary random value, stored unencrypted in the database. There’s no reason in treating salt as secret: it is not.

]]> By: Alexey Borzenkov http://terrbear.org/?p=210&cpage=1#comment-851 Alexey Borzenkov Fri, 08 Jan 2010 17:39:04 +0000 http://terrbear.org/?p=210#comment-851 I notice that you don't use salt in your database. In my solutions I use ajax to request salt for the user and then scramble it using salt and per-login secret value. This way I am protected from database leaks. Look at http://git.kitsu.ru/mine/quicknote.git in public/javascripts/users/login.js and other logic. But thanks for pointing out HMAC and sha256 plugin for jquery. :) I notice that you don’t use salt in your database. In my solutions I use ajax to request salt for the user and then scramble it using salt and per-login secret value. This way I am protected from database leaks. Look at http://git.kitsu.ru/mine/quicknote.git in public/javascripts/users/login.js and other logic.

But thanks for pointing out HMAC and sha256 plugin for jquery. :)

]]> By: Donald Parish http://terrbear.org/?p=210&cpage=1#comment-850 Donald Parish Fri, 08 Jan 2010 16:26:18 +0000 http://terrbear.org/?p=210#comment-850 Also is similar to WSSE used for ATOM authentication (http://www.xml.com/pub/a/2003/12/17/dive.html). This is an extension to HTTP authentication that hashes the password with a nonce sent in a challenge from the server and the current date. It does require the password to be stored on the server in plaintext. Also is similar to WSSE used for ATOM authentication (http://www.xml.com/pub/a/2003/12/17/dive.html). This is an extension to HTTP authentication that hashes the password with a nonce sent in a challenge from the server and the current date. It does require the password to be stored on the server in plaintext.

]]> By: Donald Parish http://terrbear.org/?p=210&cpage=1#comment-849 Donald Parish Fri, 08 Jan 2010 15:09:20 +0000 http://terrbear.org/?p=210#comment-849 IamJosh did something similar using RSA encryption by creating a public/private key, and encrypting the password with the public key, while storing the private key in session (make sure you use EncryptedCookieStore if you are using CookieStore!). See: http://iamjosh.wordpress.com/2008/03/18/encrypting-login-password-without-ssl-in-ruby-on-rails/ Don't forget, the standard HTTP way to authenticate without sending passwords in the clear is HTTP Digest Authentication (RFC2617) IamJosh did something similar using RSA encryption by creating a public/private key, and encrypting the password with the public key, while storing the private key in session (make sure you use EncryptedCookieStore if you are using CookieStore!). See: http://iamjosh.wordpress.com/2008/03/18/encrypting-login-password-without-ssl-in-ruby-on-rails/

Don’t forget, the standard HTTP way to authenticate without sending passwords in the clear is HTTP Digest Authentication (RFC2617)

]]> By: terry http://terrbear.org/?p=210&cpage=1#comment-847 terry Thu, 07 Jan 2010 15:51:40 +0000 http://terrbear.org/?p=210#comment-847 @Mike 1) The password is not stored as plain text on the server side, it's stored as an SHA256. 2) Brute forcing a hash is always a possibility. I don't know of any encryption scheme that prevents brute force attacks. 3) I think you're missing the point of this post. It's for when SSL isn't necessary or wants to be avoided, but you want to keep a password more secure than sending it as plaintext to the server. @Mike
1) The password is not stored as plain text on the server side, it’s stored as an SHA256.

2) Brute forcing a hash is always a possibility. I don’t know of any encryption scheme that prevents brute force attacks.

3) I think you’re missing the point of this post. It’s for when SSL isn’t necessary or wants to be avoided, but you want to keep a password more secure than sending it as plaintext to the server.

]]> By: mike http://terrbear.org/?p=210&cpage=1#comment-846 mike Thu, 07 Jan 2010 15:47:09 +0000 http://terrbear.org/?p=210#comment-846 I see some issues with this: The first rule of cryptography is that you don't create a cryptographic scheme unless you are a real cryptographer. The mechanism presumes that you are storing passwords in clear text on the server side, which is a massive no-no. You should never store passwords in the clear, or even as a simple hash. You use salts for good reason: they prevent simple lookups of passwords using an MD5/SHA rainbow table. Also, if the data passed from client to server is intercepted, everything is provided to enable off-line brute-force recovery of the password. The message-portion of your HMAC consists of the username and timestamp, which is passed in the clear, so I know half the equation. Using the SHA-256 of the password as the key does nothing to improve things, except for adding a minute computational exercise to produce a potential key. I wouldn't waste my time trying to figure out a way to securely pass a salt to the client. You're not going to without implementing public-key encryption. The solution is: 1. Be good, and salt&hash your user's passwords when you're storing them in a DB. 2. Use SSL to encrypt the authentication. 3. If you are worried about brute-forcing passwords, then rate-limit logins or set up account lockouts after X number of failed attempts. I see some issues with this:

The first rule of cryptography is that you don’t create a cryptographic scheme unless you are a real cryptographer.

The mechanism presumes that you are storing passwords in clear text on the server side, which is a massive no-no. You should never store passwords in the clear, or even as a simple hash. You use salts for good reason: they prevent simple lookups of passwords using an MD5/SHA rainbow table.

Also, if the data passed from client to server is intercepted, everything is provided to enable off-line brute-force recovery of the password. The message-portion of your HMAC consists of the username and timestamp, which is passed in the clear, so I know half the equation. Using the SHA-256 of the password as the key does nothing to improve things, except for adding a minute computational exercise to produce a potential key.

I wouldn’t waste my time trying to figure out a way to securely pass a salt to the client. You’re not going to without implementing public-key encryption.

The solution is:
1. Be good, and salt&hash your user’s passwords when you’re storing them in a DB.
2. Use SSL to encrypt the authentication.
3. If you are worried about brute-forcing passwords, then rate-limit logins or set up account lockouts after X number of failed attempts.

]]>