Indeed. md5 hash on password + random token is industry standard now. It would be good to have that here.
MD5(password, nonce) is horribly insecure.
http://www.matasano.com/log/958/enough-with-the-rainbow-tabl...
Why you shoud never use your favorite password on News.YCombinator.com
41–50 of 136 posts
Re: Why you shoud never use your favorite password on News.YCombinator.com
#42Earlier quoted context omitted.
I'm a bit confused here. If you were to store salted passwords when you create an account: salt = randomstring(4) hashed_pw = salt + ':' + sha1(salt + password) store(hashed_pw, login_name) How do you then verify this? In other words, how do you send the user the salt and the nonce if you don't know who the user is ahead of time?
Here is how it generally works. This method provides a salt along with a nonce. In general, only the actual user knows the password. Start: User registers for a service and submits a username + password. The password is salted and hashed in the browser and then sent to the server over a secure connection along with other info. like username etc... Then when somebody wants to so log in: Server sends a random nonce and…
You're not thinking this through.
Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security.
If attackers don't have access to raw traffic, sending over the plaintext password is just fine, because attackers don't have access to raw traffic.
I'm sorry, but security isn't an obstacle course. For evidence, go research what percentage of online bank transactions in Brazil were fraudulent in 2007. There is no clever solution to this problem.
Send passwords over SSL, or don't care about the password you send.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#43Digest access authentication is an immediate and halfway decent fix. At one point I thought this was a big enough problem to write a greasemonkey script hashing passwords clientside for every website. But it just isn't a big interest of mine.
> Digest access authentication is an immediate and halfway decent fix. It really is a shame that browsers have such a terrible UI for HTTP auth.
Before you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies.
I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions with HTTP auth.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#44Earlier quoted context omitted.
There are still ways to add a little extra security for non-ssl logins. One way is by hashing the password via javascript with a random number provided by the server before posting it via HTTP. (see http://pajhome.org.uk/crypt/md5/auth.html )
That adds no security at all . Security is not an obstacle course.
Why doesn't it add security? It means the password isn't being transmitted in cleartext (it's using an irreversible hash). For the record, Yahoo! use that exact technique on their login page (though I'm not sure why as it's served over https).
UPDATE: I see from a post further down that you're talking about re-writing the JavaScript in transit. Fair point.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#45Earlier quoted context omitted.
Look at the title of post - i'm not showing you HTTP is plaintext based - I said exactly "Never use the same login for 2 websites"
"Never use the same login for 2 websites" I call BS to that. Fair enough for websites that use your banking or credit card information, but for the rest? I don't think so. For irrelevant sites such as Hacker News, Reddit, whatever other minor web 2 site you can think of, you should ALWAYS use the same password. Why fart around with a ridiculous number of passwords for websites that are nothing more than minor daily d…
Agreed - now I would use my 3rd tier pwd for news.YC.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#46Earlier quoted context omitted.
There are still ways to add a little extra security for non-ssl logins. One way is by hashing the password via javascript with a random number provided by the server before posting it via HTTP. (see http://pajhome.org.uk/crypt/md5/auth.html )
That adds no security at all . Security is not an obstacle course.
It adds a little. It means that a passive eavesdropper has to mount a offline dictionary attack before knowing the plaintext password. That's better than nothing.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#47Earlier quoted context omitted.
I use a hash. I don't quite know how secure that alone is though. My thoughts are if my server is compromised(and an endless stream of attempts lead me to believe it's not extremely unlikely) having both the scripts with the database could deduce the passwords. Am I wrong?
You are. One of the defining properties of a cryptographic hash is that you cannot easily deduce the input given the output, nor can you easily construct an input to produce a given output. (see the overview at http://en.wikipedia.org/wiki/Cryptographic_hash ) However, it's still possible to do a dictionary attack on the database of hashes ("is the hash of "password" the same as the user's password hash? yes? Bingo!"…
Provided, of course, that P != NP.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#48Earlier quoted context omitted.
> Digest access authentication is an immediate and halfway decent fix. It really is a shame that browsers have such a terrible UI for HTTP auth.
Before you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies. I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions wit…
What's silly about Digest?
Re: Why you shoud never use your favorite password on News.YCombinator.com
#49Earlier quoted context omitted.
Before you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies. I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions wit…
What's silly about Digest?
It's obviously less secure than SSL.
Re: Why you shoud never use your favorite password on News.YCombinator.com
#50Earlier quoted context omitted.
That adds no security at all . Security is not an obstacle course.
It adds a little. It means that a passive eavesdropper has to mount a offline dictionary attack before knowing the plaintext password. That's better than nothing.
No. Respectfully, you too have failed to think this through. Attackers with access to raw traffic can (and routinely do) change the traffic. Attackers will simply rewrite your hashing Javascript in transit.