

Secure Persistent Login With Very Little SSL - hayroob
http://getitdownonpaper.com/?p=15
A proposal for a secure login system using SSL only at initial login, but maintaining robust authentication and defending against man in the middle and replay attacks.
======
Saavedro
A couple issues to note off the top of my head:

    
    
      "In order to login, a user will be presented with a 
       standard html form on a page that may or may not be 
       encrypted, at this point SSL is not relevant."
    

SSL is -quite- relevant at this point. You are specifically addressing MITM
situations, and an MITM can, if you do not use SSL to send the log in form,
send a modified login form which either posts to a different attacker-
controlled server or simply attempts to post to your server in the clear,
allowing the attacker to capture the users credentials in cleartext.

Also, it seems that after you use the SSL session to get the AES-encrypted
cookies to the user, the user still has to have an AES key stored on their
system (and the AES key is what allows the user to continue making requests by
proving the user's knowledge thereof by encrypting randomly generated "hashes"
and getting new AES keys). What would prevent an MITM attacker, once you are
no longer using SSL, from sending down a modified page to the user with
malicious javascript that sends the user's current AES key to the attacker,
thereby allowing the attacker to hijack the user's session?

While this scheme -should- prevent offline/passive replay attacks, it does not
seem to mitigate an active Man-In-The-Middle attack.

ADD: What I would suggest if you could not afford to run your site in full-
SSL, is that you require SSL for any operation that is not a READ or is a read
of sensitive account info. Don't allow a user to post messages, delete
records, etc. over regular HTTP. If some MITM steals your users cookies, then
they will at best be able to, say, read a bit more of your user's mail than
they would have been able to had they just sniffed the portion that your user
actually requested. (Not that I would ever recommend not using full-SSL for
email. Remember "Forgot your password?") Also, do not give a "Remember this
computer forever" option when not using full-SSL (or at least make the
"forever" cookie a secure cookie and still expire the non-secure session
cookie) and ALWAYS expire cookies on the server side.

~~~
hayroob
SSL is relevant and in my actual implementation, which I am prepping now, I do
use SSL on the login form, but technically, the form it is submitting to needs
to be SSL, but the form itself does not.

Since I wrote the article I have made some small adjustments to the AES key
dialogue, they key is generated at the login form using javascript then sent
as an ssl cookie to the authentication form and also stored into a local
persistent storage, which is not accessible (barring an exploit.) Once the
auth page is reached the aes and guid cookies are cleared. I suppose that a
script could be crafted to cause the user to reveal the key and guid stored in
persistent storage, this is something I am still working on securing against.

I will consider your suggestions carefully and attempt to integrate them as I
work to code this out.

I have posted this discussion into the comments in the article and will be
updating it tonight to reflect this conversation. Thank You.

~~~
there
_the form it is submitting to needs to be SSL, but the form itself does not_

then how do you guarantee the form is going to submit to an SSL-protected
resource? the form and all of your javascript has to be sent over SSL,
otherwise any of it can be tampered with to simply bypass your logic and post
the form contents to an unencrypted resource.

if you haven't already seen it, watch moxie's blackhat presentation about ssl:

[https://www.blackhat.com/html/bh-dc-09/bh-
dc-09-archives.htm...](https://www.blackhat.com/html/bh-dc-09/bh-
dc-09-archives.html#Marlinspike)

~~~
hayroob
That seems like viable thought. I will watch the presentation when I get a
chance, but for now I will modify the article to consider this scenario and my
code already forces SSL on the login page and the authentication script.

------
TravisLS
_the password is hashed with sha1 so that the database does not need to store
the actual password_

This recommended approach is not good security practice for password storage.
If the database is compromised, your passwords are vulnerable to rainbow table
attacks. See <http://en.wikipedia.org/wiki/Rainbow_table>

~~~
hayroob
ya I should probably being using HMAC

~~~
Saavedro
Passwords always should be salted. (meaning a -different- nonce for each
password) This prevents rainbow tables from being useful. Instead of a raw
hash function, you should (for maximum security) be using something
specifically designed to be expensive: read pbkdf2, bcrypt, scrypt; This will
make even dictionary attacks very difficult. If someone has cracked your db
they also probably also have access to your HMAC key, at which point cracking
can still be parallellized and is not significantly slowed.

~~~
hayroob
Is there a reference implementation that you like and that is well documented.

------
MichaelApproved
Securing the login is hard. Facebook submits to an SSL page but I suspect the
rest of the time their persistent login cookie is free to snatch.

------
erqwersadf
Another approach to securing sessions without (much) SSL is SessionLock:
<http://ben.adida.net/projects/sessionlock/>

------
erlanger
If your document isn't printable, you should provide a printable version.
Unlike me, not all users will fiddle with Firebug and Print Preview for a few
minutes.

