First time login and password resets...
Hello,
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
From my point of view you have it pretty much all covered. my personal
process is
Generate a temporary token (30 min to 1 day max). So email will be
useless after that period in case the computer or user email is
compromised
Send a HTTPS link to user with the temp token. Avoid wire sniffing
The end user will have answer a challenge question (one of at least 2
entered on registration) and then reset its password. Supply an identity
element, in this case challenge response instead of previous password
and reset password as it should be in hash or salted hash format thus
not reversible nor displayable to user.
Request for password reset and password reset success should be notified
to user via registered email
This approach implies users register themselves, also, if your site is
not public but corporate level and contains sensitive information, I
strongly recommend you also add a manager authorization step to keep
accountability for system accesses granted.
As everything in security the approach is not perfect, but I think is
good enough due to limited time window and measures taken to avoid
disclosing the password.
Regards,
Juan C Calderon
From: websecurity-bounces@lists.webappsec.org
[mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Milton
Smith
Sent: Monday, January 31, 2011 10:00 AM
To: websecurity@lists.webappsec.org
Subject: [WEB SECURITY] First time login and password resets...
Hello,
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
While our solution is not perfect it is a balance between security and getting business done. When our users request a password reset we leave a one-time password in their voicemail. Of course if someone compromises a users voice mail they can easily get a password for their account so it is not perfect!
John R. McKean II, CISSP(r)
Sr. Information Security Analyst
From: websecurity-bounces@lists.webappsec.org [mailto:websecurity-bounces@lists.webappsec.org] On Behalf Of Milton Smith
Sent: Monday, January 31, 2011 8:00 AM
To: websecurity@lists.webappsec.org
Subject: [WEB SECURITY] First time login and password resets...
Hello,
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
Juan is expressing current best practice. A very reasonable risk posture.
I was also impressed with some of the ideas in :
... Takeaway: avoid email and either ask a lot of questions to allow for the
reset, and/or possibly use a cell phone as a second factor. Email is
inherently plaintext and insecure.
-Jim Manico
http://manico.net
On Jan 31, 2011, at 11:19 AM, "Calderon, Juan Carlos (GE, Corporate,
consultant)" juan.calderon@ge.com wrote:
From my point of view you have it pretty much all covered. my personal
process is
Generate a temporary token (30 min to 1 day max). So email will be useless
after that period in case the computer or user email is compromised
Send a HTTPS link to user with the temp token. Avoid wire sniffing
The end user will have answer a challenge question (one of at least 2
entered on registration) and then reset its password. Supply an identity
element, in this case challenge response instead of previous password and
reset password as it should be in hash or salted hash format thus not
reversible nor displayable to user.
Request for password reset and password reset success should be notified to
user via registered email
This approach implies users register themselves, also, if your site is not
public but corporate level and contains sensitive information, I strongly
recommend you also add a manager authorization step to keep accountability
for system accesses granted.
As everything in security the approach is not perfect, but I think is good
enough due to limited time window and measures taken to avoid disclosing the
password.
Regards,
Juan C Calderon
From: websecurity-bounces@lists.webappsec.org [mailto:
websecurity-bounces@lists.webappsec.org] *On Behalf Of *Milton Smith
Sent: Monday, January 31, 2011 10:00 AM
To: websecurity@lists.webappsec.org
Subject: [WEB SECURITY] First time login and password resets...
Hello,
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
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Hi,
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.
- Enter email address, get email containing link with activation code,
click link, answer security questions, reset password. - 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.
http://www.b2cmarketinginsider.com/social-media/the-pros-and-cons-of-facebook-social-authentication-012453
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.
Paul
On 31/01/2011 16:00, Milton Smith wrote:
Hello,
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
Paul,
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.
-Jim Manico
http://manico.net
On Feb 2, 2011, at 11:17 AM, Paul Johnston paul.johnston@pentest.co.uk wrote:
Hi,
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.
- Enter email address, get email containing link with activation code,
click link, answer security questions, reset password. - 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.
http://www.b2cmarketinginsider.com/social-media/the-pros-and-cons-of-facebook-social-authentication-012453
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.
Paul
On 31/01/2011 16:00, Milton Smith wrote:
Hello,
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
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
Surprised to hear from so many folks I know. Small world. Very helpful information. Thanks to everyone for taking a look and for those that responded. --Milton
On Jan 31, 2011, at 8:00 AM, Milton Smith wrote:
Hello,
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