And no emailing 10,000 people requiring them to reset there password would not be classified as "easy" to me. (Brute forcing them doesnt count either
This is hypothetical so don't bother going through great lengths to come up with a solution.
Moderator: General Moderators
Lets assume that you are doing logins in a secure fashion, and already send the password PRE-HASHED via md5. (In other words, the user never sends $password in cleartext.. a javascript md5 library hashes it and replaces it).jshpro2 wrote:What if you had like 10,000 members who's passwords were stored as md5 hash's and you wanted to upgrade to sha1 or sha256 or something, there would be no easy way to do that would there?
I don't understand how that is more secure. This means that we'll accept any sort of hash: if the database's contents are leaked, then they can use the system's willingness to accept hashes to log on to any account they know the hash for. Am I missing something here?Lets assume that you are doing logins in a secure fashion, and already send the password PRE-HASHED via md5. (In other words, the user never sends $password in cleartext.. a javascript md5 library hashes it and replaces it).
Its the poor-man's SSL-replacement to avoid sending passwords in the clear. There's different opinion's on whether its more secure or not. You are still comparing the sent value to the (old) hash in the DB, so it must match. You won't accept any hash.Ambush Commander wrote:I don't understand how that is more secure. This means that we'll accept any sort of hash: if the database's contents are leaked, then they can use the system's willingness to accept hashes to log on to any account they know the hash for. Am I missing something here?Lets assume that you are doing logins in a secure fashion, and already send the password PRE-HASHED via md5. (In other words, the user never sends $password in cleartext.. a javascript md5 library hashes it and replaces it).
Because it avoids passing the password in cleartext, and migrates users to a hash function that is not currently known to be broken/insecure.Ambush Commander wrote:I don't understand how that is more secure.
Not any. Notice that you only accept 2. Sha, or md5. Also, you only accept md5 until they have an sha pass, and only accept sha once they've migrated.Ambush Commander wrote:This means that we'll accept any sort of hash:
No, thats correct. Hashing passwords solves two of eight problems in logins: Cleartext transmission and storage. There are *eight*, each with unique differences, and needs.Ambush Commander wrote: if the database's contents are leaked, then they can use the system's willingness to accept hashes to log on to any account they know the hash for. Am I missing something here?
If anyone is wondering what that means, I believe http://www.awprofessional.com/articles/ ... Num=1&rl=1 is what Roja is talking about.There are *eight*, each with unique differences, and needs.
Hmm.. we're not on the same channel. I'm saying that if the passwords are leaked, well, if you stored hashed versions, then it's not that bad right? So if the system accepts hashes for a direct check with the value in the database: eg:Not any. Notice that you only accept 2. Sha, or md5. Also, you only accept md5 until they have an sha pass, and only accept sha once they've migrated.
So at most, its two, and thats only one-time. You aren't "trusting" their hash either - you are checking it against a secret.
Sorry, no. I've talked about the different steps to a secure login system in roughly a dozen threads here on the forums.. each time someone asks a question something like "Yeah, but step one doesn't solve steps two through eight - SO ITS INSECURE!", which is like saying that if flour and milk don't make cake, nothing can.Ambush Commander wrote: If anyone is wondering what that means, I believe http://www.awprofessional.com/articles/ ... Num=1&rl=1 is what Roja is talking about.
Its "less bad" than if you stored and sent the passwords cleartext.Ambush Commander wrote: Hmm.. we're not on the same channel. I'm saying that if the passwords are leaked, well, if you stored hashed versions, then it's not that bad right?
If you DONT use javascript, then you can be sure that the password *IS* being sent in cleartext. Thats bad. Sniffing on the network is extremely common these days, especially on broadband connections. Thats why I recommend js hashing.Ambush Commander wrote: So if the system accepts hashes for a direct check with the value in the database: eg:
hash_sent == hash_in_database
rather than
hash(password) == hash_in_database
with the hash() a mandatory function applied to all incoming data. For the JavaScript implementation, there's no guarantee that the hash was the result of the JavaScript operation, maybe it was injected into the request.
The password isn't safe. If the password is sent cleartext, it is likely to be compromised, and then the hash is automatically applied to it. Thats why cleartext transmission is very bad. Its step #1.Ambush Commander wrote: In the end, however, this method is simply an extra security measure, I guess. If the end user doesn't support Javascript, you can always fall back to cleartext transmission, and in the event the hash is sniffed out, at least the password is safe.
I've just searched through many of your past threads, can you point me to one where you list the 8 steps you consider for a login system?Roja wrote:Sorry, no. I've talked about the different steps to a secure login system in roughly a dozen threads here on the forums.. each time someone asks a question something like "Yeah, but step one doesn't solve steps two through eight - SO ITS INSECURE!", which is like saying that if flour and milk don't make cake, nothing can.Ambush Commander wrote: If anyone is wondering what that means, I believe http://www.awprofessional.com/articles/ ... Num=1&rl=1 is what Roja is talking about.
This would effectively increase the chance of a collision, but I think this article was written before a lot of the md5 vulnerabilities were discovered. All in all https is the best option no hands down, but for some of us it's just not possible.We can simply repeat the MD5 operation many times, and the attacker will have to do the same for each password. Informal experiments show that doing 100 repeated hashes in JavaScript does not slow things significantly.
I was fairly certain I listed them in another thread, but I don't see them. Here are the main threads we've covered this ground in before:nielsene wrote:I've just searched through many of your past threads, can you point me to one where you list the 8 steps you consider for a login system?
I don't disagree. SSL is always the ideal. But if SSL isn't available, what then?nielsene wrote:I agree with you in principle that its stupid to throw out everything if its not perfect. I'm less comfortable about the JavaScript hash suggestions -- I'm one of the people who doesn't like to have JS enabled. If a site requires a real login, I expect SSL.
To be completely clear: They ARE less secure than SSL. The full explanation about why isn't totally needed, but your gut feeling was right on the money. They are less secure.nielsene wrote:Sites with "fake SSL", which I consider the hash method to be, normally feel *less* secure than a normal cleartext site -- most of them are seriously broken in other ways and think they are being "smart". Now'd I'd trust your sites, since you understand what you're doing and why. But I'm afraid many will take it as a golden bullet solution....
I was working on one too before I went stealth for almost a year here.Roja wrote:From the repetition and the number of times this topic has come up, it sounds like I need to write a solid tutorial that covers all the bases, explaining each of the problems and solutions needed. I was working on one for sitepoint, but never finished it.