Timeline for Is password dependent iteration count a good practice?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2019 at 13:55 | comment | added | kasperd | @simbo1905 That comment is more useful than the current answer. But as mentioned in the question the system currently doesn't support enforcing a password policy and I might not have the mandate to enforce one. If I cannot enforce a password policy, that would rule out both of your suggestions. I'll certainly look into the possibility of enforcing a password policy as I'd prefer that to status quo. Snooping on network traffic to detect users with weak passwords is a valid concern, but it will only help the attacker if it can be matched to a username. | |
| Mar 2, 2019 at 12:00 | comment | added | simbo1905 | Don’t do it is the correct answer. You are allowing users with weak passwords to force you server to do a load more work. And giving a bad user experience. And an attacker watching the traffic can see that they have a weak password. Use a password strength meter and don’t let users register weak password. Use the Troy Hunt pwnd password system. Use known best practices don’t try to invent your own. | |
| Mar 2, 2019 at 11:26 | comment | added | kasperd | @SeeYouInDisneyland I think that simply ignoring the issue might go against applicable legislation. Though I am no expert on the legislation, so I cannot say for sure. Frankly, I'd rather just do the right thing security-wise thank having to get into interpretation of legislation which isn't written with comprehensibility in mind. Also, when I come to this website asking for advice on improving security, I was expecting something a bit more constructive than don't do it. | |
| Mar 2, 2019 at 11:05 | comment | added | kasperd | How is your suggestion a weak password is a weak password - no matter how often you iterate the PBKDF any different from applying the same argument against the current default iteration count of 36000 used by the Django project (up from 12000 in earlier versions). I personally use passwords that are strong enough to be secure even when hashed just once, and I wish others would do the same. But I cannot force the users to use strong passwords. And varying the iteration count seems like a simple improvement. | |
| Mar 2, 2019 at 11:03 | comment | added | SeeYouInDisneyland | The user is the weakest link here. If you think education will fail you might as well save yourself the hassle, grab a beer, and continue as usual. | |
| Mar 2, 2019 at 11:01 | comment | added | kasperd | @VLAZ My interest is to make the system secure. At the moment I don't have a better idea on how to improve it. I will certainly also attempt a user education approach, but I don't think it is going to be effective. | |
| Mar 2, 2019 at 10:46 | comment | added | VLAZ | @kasperd then I suggest you go with this approach. It doesn't seem you are interested in being told "don't do it". | |
| Mar 2, 2019 at 10:36 | comment | added | kasperd | @VLAZ It is for a web application, so the wait in case of a mistyped password can be dealt with by the user just submitting the form again with a correct password. As long as the user doesn't hit the rate limit, they don't have to wait for the validation to complete before trying again. And the potential for a DoS vector I already addressed in the question. This DoS vector exists on any online system which uses iterated password hashing. | |
| Mar 2, 2019 at 10:30 | comment | added | kasperd | @VLAZ Unless the user tells the attacker about their short password/slow logins, I don't see how the attacker would learn. The attacker is not going to learn about the user's password length by simply probing the password form. As mentioned in the question, the database won't contain information about the password length. Until the attacker actually guesses the correct password, the system won't know how long the password is. And by the time the attacker has guessed the password, it doesn't hurt to tell the attacker that the password was too short. | |
| Mar 2, 2019 at 10:26 | comment | added | kasperd | @SeeYouInDisneyland The case of long passwords with low entropy could be addressed by a more sophisticated version using an entropy estimate to decide on iteration count rather than just password length. | |
| Mar 2, 2019 at 10:18 | comment | added | VLAZ | @kasperd wait, so you enter your credentials and it goes - "Your password is too short, you'll have to wait for this"? Doesn't that give MORE information to an attacker? If an attacker knows Bob has to wait to log in, then the attacker will just need to try short passwords. Moreover, if you are doing the 10+ sec hashing for any password, including wrong ones, then if Bob types the first few letters of his long password and hits enter by accident, he'd need to wait a lot just to be able to write the correct one. Finally, that seems like a DOS attack vector - just input many short passwords. | |
| Mar 2, 2019 at 10:18 | comment | added | SeeYouInDisneyland | Ok, so so we are talking about ridiculous amounts of iterations/waiting time. I'd guess that even with an explanation, your users would flat out reject such a process. This is a classic example of "better" security leading to less security by failing user acceptance. Security should ideally be transparent to users. If I were a users, I'd just pad my crappy pw with as until I met your "stupid security crap" (speaking as a user ;) ). As I said, you're tackling a human issue, not a code/process issue. | |
| Mar 2, 2019 at 10:08 | comment | added | kasperd | The default iteration count used by the Django version I tested is 36000. And my performance measures showed 1000000 iterations per second on the hardware on which this would be used. So the user would be waiting at most 18 seconds with the numbers used in my question. Yes, obviously the users will have to be told about this practice. | |
| Mar 2, 2019 at 9:52 | history | answered | SeeYouInDisneyland | CC BY-SA 4.0 |