[WEB SECURITY] First time login and password resets...
jim at manico.net
Wed Feb 2 12:27:46 EST 2011
I think this is fairly complete and verbose answer.
However, I politely disagree with using email as part of the password
reset or initialization vector for high risk consumer facing services.
Most banking websites have moved away from this mechanism and utilize
extensive security questions up front as well as an SMS message to
transmit a very temporary token.
I think email IS reasonable as a security token transport mechanism in
a corporate environment that utilizes S/MIME or PGP.
I also think that sending temporary passwords via any transport is
usually bad form since in implies either poor password storage or poor
password management. Ideally, insiders should never have the ability
to know or generate a users password.
On Feb 2, 2011, at 11:17 AM, Paul Johnston <paul.johnston at pentest.co.uk> wrote:
> For registration, one option is to side-step the whole problem and have
> users self-register and enter a password over HTTPS.
> Many systems accept the risk of using email for registration and resets.
> The usual technique is to have a token that's time limited and only
> valid once. Whether this is a temporary password that they're forced to
> change or an activation code makes little difference to the security of
> the system.
> As someone else mentioned, a good mitigation is to require the user to
> answer some additional questions. This could be security questions like
> "name of your first pet" or account details such as DOB or postcode.
> There are a few ways you can order a password reset, e.g.
> 1) Enter email address, get email containing link with activation code,
> click link, answer security questions, reset password.
> 2) Enter email address, answer security questions, get email, click
> link, reset password.
> Approach (2) has the benefit that it's harder for an attacker to
> generate spurios reset emails. But you need to take care that the user
> who clicks the link is the same user who answered the questions. This
> can be done with a cookie; I've also seen sites display half the
> activation code on screen and send half by email.
> Of course, email isn't the only means you have to contact a customer,
> you can also use: phone/sms, postal letter or even a visit in person,
> perhaps with the customer visiting an office and proving identity using
> photo ID, or more advanced biometrics. There's also the potential to
> link to other identity systems, e.g. requiring a $1 payment to be made
> on a credit card with the name and billing address matching that on the
> account to be reset.
> I've noticed Facebook have a novel approach called Social Authentication
> where you're asked to identify friends from photos, although I doubt any
> site other than a social network would have the data necessary to do this.
> Ultimately this all depends on how sensitive your site is, and how much
> can be spent securing this. Activation codes by postal letter I've only
> seen done by online banking, where it is the norm for registrations.
> Reset codes by phone/sms are fairly widely supported by sites like
> Paypal and Google, although more as a fallback when the email address is
> unavailable, rather than a primary method.
> On 31/01/2011 16:00, Milton Smith wrote:
>> Wondering what everyone does to communicate first time credentials or password resets to users. There are two challenges.
>> Ensure person we communicate credentials to is the correct person (e.g., owner of credentials)
>> Do not disclose credentials in plain text over network
>> To a certain extent the computer has not helped us with these challenges. Simply reverting to phone does not solve these challenges either. For example, calling a user with their new credentials is similar to mailing the credentials in the clear. It's likely IT staff does not know the person on the other end of line and phone conversations can be intercepted.
>> The solution I have been considering is to email an HTTPS link to users. Next, mandatory password reset at logon. This prevents sniffing credentials over net. Of course, you can sniff the URL then login. However, if this is done it will be obvious to the user since they will not be able to logon with the password they were sent. A bit after the fact I realize but perhaps better than nothing. Next, what if I made the link so it's only good for 10 mins or some limited window. This helps limit the window of opportunity. Anyway, this solution is not perfect but perhaps better than passwords in the clear or calling people we don't know. Key fobs, other hardware solutions, or client side certs are likely out since it's a cloud based solution.
>> Do you have any interesting thoughts or suggestions for how you approached these challenges?
>> Kind Regards,
>> Milton Smith
> Pentest - When a tick in the box is not enough
> Paul Johnston - IT Security Consultant / Tiger SST
> Pentest Limited - ISO 9001 (cert 16055) / ISO 27001 (cert 558982)
> Office: +44 (0) 161 233 0100
> Mobile: +44 (0) 7817 219 072
> Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy
> Registered Number: 4217114 England & Wales
> Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK
> The Web Security Mailing List
> WebSecurity RSS Feed
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> websecurity at lists.webappsec.org
More information about the websecurity