0

For a web application, where we need to store and manage users (SSO or openauth or what not is off the table), where we manage important business data, how risky is it to use an email address + password as the sign in?

For the last 15 years or so, encryption and protection techniques have improved, but we continue to use a proprietary user id, akin to using your bank card number for online banking; an id that will not be reused elsewhere. Customers and product owners are pushing to use email address because it is easier to remember.

I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?

I'm looking for some article or argument why using email+password for a site with sensitive business/financial information would be dangerous; or why it is not so bad. Again, I realize that provisioning our own accounts is not the ideal thing and am not looking for solutions at outsourcing authentication.

Craig Celeste
  • 12,207
  • 10
  • 42
  • 49
  • 1
    This question might be a better fit for http://security.stackexchange.com/ -- but first check whether similar questions have already been asked there. A thought: If users choose their own passwords, some of them are likely to re-use passwords they use on other sites; then compromising the other sites would compromise accounts on yours. I can't think of a good way to prevent that (since you don't have access to other passwords) other than assigning passwords -- which means those passwords have to be *securely* given to the users. – Keith Thompson Mar 11 '15 at 18:24

2 Answers2

2

The "risk" of using a single authentication method for signing onto your application is difficult to determine without a risk assessment, and clearly defined system boundaries.

NIST 800-61 and NIST 800-63 gives guidelines on authentication methods for different levels of sensitive systems (in your case, a application). It will give you ideas on how to present your argument, and maybe an alternative solution, i.e., multi-factor authentication if the customer wants to authenticate using an e-mail address. This would mitigate the risk associated with malicious websites which collected e-mail addresses and passwords.

Keep in mind, password policy can also be managed to mitigate the risk behind a single authentication method using an e-mail and a compromised password associated with that e-mail.

All in all, it's not the ID that is important, but the authentication method and policies in place to mitigate the risks.

dtb_pen
  • 21
  • 1
  • 4
1

Using email + password as credentials is the widely accepted method of allowing users to log into sites on the web.

The advantage of using email is that everyone remembers their email address, whereas people will have difficulty in remembering which username or user ID they first signed up with if this is not their email address.

Username should not be considered private. This is the job of the password. Encourage your users to use a password manager such as LastPass where it can generate a 20 character completely random password (128 bits - uncrackable) which is different per site. LastPass will remember the username if this is not their email, so that solves this problem, however not using email can bring other problems such as username enumeration. If any signup function asks for a user to specify their username and you say that it is already in use, an attacker can use this to narrow the list of users in order to prepare for a password guessing attack. If you ask for email as step one of password reminder or signup forms, the system can send an email with a password reset link if already registered, or send an email with a link to the next step in the registration process if not.

In the end it all comes down to the value of the data your application is protecting. Adding two factor authentication is always a good step and can protect against password guessing and password reuse.

SSO or openauth or what not is off the table

Why is the case? Can't you use OAuth with claims based authorisation? You can still secure your application and make sure only the correct business users have access - it would just be that another entity is managing access for you.

I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?

Credential harvesting?

Community
  • 1
  • 1
SilverlightFox
  • 32,436
  • 11
  • 76
  • 145
  • Thanks for the response! re: "remembering which username or user id they first signed up with"... that's the trick. Nobody signs up for our service. Their employers mandate that they use our service. Maybe I'm splitting hairs. re: "Using email + password as credentials is the widely accepted method" that's the concern. Many people (maybe just some? more than none, I think) are not vigilant with choosing unique passwords. If people use the same password for more than one site, then it only takes one malicious site to know the password for all the sites. Maybe it's not a concern. – Craig Celeste Mar 12 '15 at 13:58
  • I'm of the belief that if you sacrifice usability, you sacrifice security. Make something that is theoretically more secure, then users will find a way round your security defeating the object. I don't think making username secret is the way forward - this is what password is for. You could mandate that all logins must be protected by some sort of two factor authentication. This would protect against users reusing passwords elsewhere that attackers then use to target your site. – SilverlightFox Mar 12 '15 at 15:00