Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re^3: It's Time for Everyone to Change Passwords!

by ig (Vicar)
on Jul 29, 2009 at 18:45 UTC ( #784333=note: print w/ replies, xml ) Need Help??


in reply to Re^2: It's Time for Everyone to Change Passwords!
in thread It's Time for Everyone to Change Passwords!

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.


Comment on Re^3: It's Time for Everyone to Change Passwords!
Re^4: It's Time for Everyone to Change Passwords!
by Anonymous Monk on Jul 29, 2009 at 19:27 UTC
Re^4: It's Time for Everyone to Change Passwords!
by Anonymous Monk on Jul 29, 2009 at 19:27 UTC
Re^4: It's Time for Everyone to Change Passwords!
by merlyn (Sage) on Jul 29, 2009 at 22:47 UTC
    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.

      Even better.

      Not so good if there is enough information in a single email to allow a successful "login" and takeover of the account but this risk could be mitigated by supporting encryption of the email. It would also be good if the link would no longer work once the password had been changed and after some time (a few days perhaps).

Re^4: It's Time for Everyone to Change Passwords!
by Limbic~Region (Chancellor) on Jul 30, 2009 at 13:26 UTC
    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.

    Cheers - L~R

      It's not a nitpick to correct a fundamentally flawed statement, particularly in a field where errors and misunderstanding can have such severe consequences. You are correct. My bad. Thanks much.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://784333]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2014-12-27 02:50 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls