I am working on an intranet site and need to choose one way of two: 1. Disable an option when a user can change a password to any word he likes, for example, pass123. This way there will be a button to generate a new password using some complex algorithm and then user accepts its using. 2. Make standard password changing function. This way user can enter any password he likes and save it. Thanks.
+1
A:
I'd say it's good if you only give the user a button to generate a new password, then he can't use the same password on every site.
Longpoke
2010-09-09 11:27:43
No, if you generate a password for the user, they won't be able to memorize it, so they'll defeat the whole point by writing it down, probably on a yellow sticky they'll attach to the side of their monitor.
Steven Sudit
2010-09-09 11:28:42
@Steven: Store it in browser etc. Do you expect me to memorize different passwords for 50 different sites I use? no. and there is no way in _hell_ I am using the same password on them all. Passwords are a legacy solution (there are rare cases where they are acceptable, like encrypting a disk or smartcard), we have real authentication techniques, but until then, you better use a long random password and perhaps only one that you actually remember to encrypt your disk. Or... do you want to use your mail etc from public networks? That's also insecure.
Longpoke
2010-09-09 11:32:41
If it's stored in the browser, you might as well just hand them a persistent cookie.
Steven Sudit
2010-09-09 12:33:05
In any case, it's not like passwords are going away. In the office, I have a smartcard and disk encryption, but I still need to know my password.
Steven Sudit
2010-09-09 12:35:02
@Steven: Cookies are volatile in nature, so that wouldn't be that great of an idea. I personally use 100-200 char passwords for every site since they lack proper authentication, it works just as well. In the end it really doesn't matter because 99.9999% of the open web is insecure in an unimaginable number of ways, but this is just good practice for personal use. I agree that passwords have their use though, it's just a horrible idea for the open Internet and even worse for an internal net.
Longpoke
2010-09-09 13:10:10
I'm not sure I understand. Increasing password size is only useful to the point where it impairs a brute force attack. Unless they're morally bankrupt and/or grossly incompetent, the password is going to be hashed down to a fixed size, which means that shorter inputs could generate it. I think you had it right when you said that, in the end, it doesn't matter how big your password is (past a certain point) because the weakness is elsewhere.
Steven Sudit
2010-09-09 18:34:23
@Steve: I just put it high to play it safe. Pretty much anything over 8 digits with decent a charset is gonna make a bruteforce attack be unfeasible (unless the admins are blind and don't notice billions of requests?). And I don't have to bother trying to calculate how powerful of an attacker who has my hashes I want to be able to stop. Then again... it's _usually_ game over when an adversary has your hashes.
Longpoke
2010-09-09 19:32:24
I guess it comes down to overkill. Longer passwords don't provide more security, but they do encourage post-it notes.
Steven Sudit
2010-09-09 19:36:08
+5
A:
If it's an intranet site, then authentication should generally be handled through LDAP, not explicit password entry.
Steven Sudit
2010-09-09 11:27:50
@Longpoke: Being flamed occasionally is the price of admission at SO. :-)
Steven Sudit
2010-09-09 11:32:14
@Longpoke: I've actually seen intranet sites that use Basic authentication without SSL. The craziness of this is minimized by the fact that sniffing is made difficult by active switches and the actual authentication is still through LDAP.
Steven Sudit
2010-09-09 18:32:36
+1
A:
If you have a password strength policy, state this clearly on the form when the user chooses a new password and don't accept it if the password is not strong enough (option 1.).
Darin Dimitrov
2010-09-09 11:29:13
That's certainly good general advice. Not sure that it helps here, though.
Steven Sudit
2010-09-09 11:32:44
A:
It just depends on how secure you want the site to be.
If you allow them to change their own password, then I would suggest that you have some sort of "Password Strength" visual aid to help them pick a strong password. Then maybe only except strong passwords.
Only allowing them to change their password to another password generated from a complex algorithm would probably result in them not remembering it, however this way you can always count on strong passwords. Emailing them the password would mean that they would not have to write it down somewhere, and then even though it is written down it would then be securely hidden behind their email login.
Tim B James
2010-09-09 11:32:54
Uh, no, it's a bad, bad idea to ever email them a password. Even if they forget it, just send them a link that they can use once to set a new password.
Steven Sudit
2010-09-09 12:34:12
Again it depends on the level of security. It is best not to email them the password when they have set it. If they forgot their password however and could not log into the system, you could email them a link to reset the password (which would require some answers to security questions), or you could send them a new random password which they would have to change once logged in.
Tim B James
2010-09-09 15:59:27
Again, no. Sending them a link that can be used to change the password is much better than sending them a password, because the former can be made to expire quickly and not be reusable. These are not sound practices. I didn't downvote you when you first answered, but since this has been mistakenly accepted, I'm downvoting now to flag it as broken.
Steven Sudit
2010-09-09 18:30:49
I agreed with you on the link. I only suggest the email of password as it is built into the asp.net membership password recovery, which many sites use.
Tim B James
2010-09-09 19:50:33