|
Re^2: It's Time for Everyone to Change Passwords!
by tirwhan (Abbot) on Jul 29, 2009 at 09:50 UTC
|
I suggest everyone's password be randomized.
There is a danger in that, because several people (especially users with old accounts) will not have updated their email address and will therefore not receive their new password. Despite that, I strongly support this suggestion, dealing with people who have lost access is going to result in a lot less pain than having malicious kiddies logging onto overlooked accounts for months to come.
Also, I think virtualsue is absolutely right, take the site down now and don't put it back up until it's running on a known-clean machine.
| [reply]
[d/l] |
Re^2: It's Time for Everyone to Change Passwords!
by JavaFan (Canon) on Jul 29, 2009 at 09:26 UTC
|
Not only that, but there are also people who haven't been to perlmonks for quite some time (perhaps with the intent to never return). I guess we don't have those accounts to be misused either. | [reply] |
Re^2: It's Time for Everyone to Change Passwords!
by RMGir (Prior) on Jul 29, 2009 at 11:53 UTC
|
A nice-to-have feature would be a "gimme a new random password and instantly send me a reminder" button on the settings page where the password gets changed.
In fact, I'm sure that's what the "I forgot my password" button does - maybe all we need to do is make that button easier to find for a logged-in user.
Which reminds me, it's not obvious where "Change password" is - I wandered around my profile for a while before finding it.
| [reply] |
|
|
The password reminder (as I used it yesterday) doesn't set a new password. It sends current password in an email.
If the passwords were encrypted, as they should be, then the current password reminder function would not be possible.
If a password reset ability is provided to unauthenticated users (those who have forgotten their passwords can't authenticate) this function can be abused to interfere with legitimate access. Any unauthenticated user can request a password reset for any other user, as long as they know whatever is used to specify the account (typically a login ID or email address).
This risk can be mitigated by having the password reset function set a new additional password if the user is unauthenticated, without invalidating the current password. Only if the user is currently authenticated should the password reset function invalidate previous passwords. This presumes an authentication system that supports multiple concurrent passwords.
Security can be improved by setting a short expiry and limiting the number of uses of the password set by the password reset function available to unauthenticated users.
If the new passwords are distributed by email, then the user accounts are only as secure as the email delivery system. Ideally, the system would support but not require encrypted email for new password distribution.
| [reply] |
|
|
If a password reset ability is provided to unauthenticated users (those who have forgotten their passwords can't authenticate) this function can be abused to interfere with legitimate access. Any unauthenticated user can request a password reset for any other user, as long as they know whatever is used to specify the account (typically a login ID or email address).
Who said anything about a reset? You have a form you can surf to, to say "Hey, I'm merlyn, I forgot my password". It emails you a link with a strong crypto key that when you visit that link, you're *logged in* to a password reset form.
Thus, any number of invocations of that page would not affect me if I was continuing to already know my password.
Most sites get this wrong. {sigh}
You'd think common password patterns would be already firmly tested and entrenched in every webdevs mind, after, say, a decade and a half of the web? I guess not.
-- Randal L. Schwartz, Perl hacker
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
| [reply] |
|
|
|
|
ig,
If the passwords were encrypted, as they should be, then the current password reminder function would not be possible.
I know this thread is about something far more serious then nitpicking wording, but I still feel it necessary to point out the problem with your statement. Too many people that visit this site don't understand cryptography to know how to properly interpret what you have said.
You have implied that if something is encrypted, that it can't be decrypted ("not be possible"). I think you meant s/encrypted/hashed/ which is a cryptographic hash and is intended not to be reversible. So how could the data be stored in the database encrypted and still allow the passwords to be emailed decrypted in plain text? One way would be to use symmetric encryption such as AES. It uses the same key to encrypt and decrypt which means the key would need to be stored in a safe place. Since the box was rooted, it is unlikely a determined individual would not have been able to eventually find and decrypt the passwords. Asymmetric encryption wouldn't be practical as a means of storing passwords as I understand the PerlMonk's design.
In a nutshell, I agree that the passwords should be hashed which is what I believe you meant by encrypted.
| [reply]
[d/l] |
|
|
|
|
| [reply] |
|
|
| [reply] |
|
|
| [reply]
[d/l] |
