Increasing login security

seamus

Purely a suggestion, I'm only putting here cos I'm a bit freaked out.
I was thinking (in bed as you do) last night about securing passwords over standard HTTP connections, and thought about using Javascript. Did a quick search, and come up with this (Cached link), which is what freaked me out, as it's almost identical to what my mind was thinking of while I was trying to go to sleep.

It's actually quite simple (for those of you who can't/don't want to read the article). The only weak point for users in boards is when logging in or changing passwords - the password is transmitted as plaintext before being hashed, stored in the DB and the hash is then sent back to the client for storage in a cookie.
All conversations that take place while logged in involve transmission of the hashed value, so for all intents and purposes, you're secure once you're logged in, but if someone has a packet sniffer or whatever, and catches you when you're logging in, it's game over.
So this process simply adds an onSubmit handler to the login form, which uses a JavaScript function to hash the value before it's transmitted, and tells the server that the value being transmitted is hashed, and not plaintext.
Non-Javascript users are unaffected, and log in the old insecure way.

It's purely something I thought I'd suggest, or put up for discussion, but it may be something that's a lot of work for a relatively minor, and low-level risk.

ecksor

Your password is hashed anyway.

This protects the original password (assuming it isn't easy to crack) but doesn't protect your boards account. An MD5 without some sort of nonce is replayable once sniffed. I think the author is a bit confused where he says its a replacement for https.

seamus

Originally posted by ecksor
Your password is hashed anyway.

This protects the original password (assuming it isn't easy to crack) but doesn't protect your boards account. An MD5 without some sort of nonce is replayable once sniffed. I think the author is a bit confused where he says its a replacement for https.

Ah yeah, definitely nowhere resembling a replacement for https.

Surely though if someone sniffs your plaintext password when logging in, it leaves your account wide open? I'm aware of the weakness of md5 (someone posted a handy little script on Security a while back), just thought this might be useful for discussion.

ecksor

Originally posted by ecksor
Your password is hashed anyway.

... if you store it in the cookie, as opposed to the initial login which is what you're talking about.

What I'm getting at is that a reply attack beats the following argument under our system.

All conversations that take place while logged in involve transmission of the hashed value, so for all intents and purposes, you're secure once you're logged in, but if someone has a packet sniffer or whatever, and catches you when you're logging in, it's game over.

ecksor

Originally posted by seamus
Surely though if someone sniffs your plaintext password when logging in, it leaves your account wide open?

If someone sniffs your hashed password your account is still wide open. I just insert your userid and hashed password into my boards cookie and hey presto.

seamus

Originally posted by ecksor
... if you store it in the cookie, as opposed to the initial login which is what you're talking about.

What I'm getting at is that a reply attack beats the following argument under our system.

You've lost me here

I thought the the way boards did it was
At login, plaintext transmitted to server ->
hashed by server and tested against DB -> stored as hashed value in a cookie if valid -> while browsing, hashed value transmitted back to server to be tested against the DB for each page.

What I'm talking about is removing step 1, by transmitting a hash instead of plaintext.

If I've completely missed it, you can smack me. I also have no idea what a reply attack is

If someone sniffs your hashed password your account is still wide open. I just insert your userid and hashed password into my boards cookie and hey presto.

Badabing badaboom.
Ah well, worth the discussion, from a learning POV for me

uberwolf

I also have no idea what a reply attack is

replay? as in the same packet is resent by the attacker. Or maybe not, I'm only a n00bie

ecksor

sorry, that should have read replay, not reply.

hashed by server and tested against DB -> stored as hashed value in a cookie if valid ->

Correct.

while browsing, hashed value transmitted back to server to be tested against the DB for each page.

Yes, but if I steal that hash from you I can replay it to the server and the server doesn't know any different. md5('foo') is a constant string.

Kev

What if the server kept a list of session id, ip address pairs.

The whole thing sound like a bit too much effort.

ecksor

Non cookie based logins do keep the IPs with each session.