2

I've been reading information on making passwords secure, but what are the reasons an attacker would want to put effort into getting the original password? If an attacker does indeed have a copy of the database, then they have a copy of the database, and all of the information they would gain by logging into the account.

Here are some of the reasons I can think of:

The user may be using the password on a different site. Some of the users data may be encrypted. The attacker may want to access the account later. The attacker may want to modify the users data, and only had read access to the server's database. The attacker did not gain all information from the database.

Would policies such as two-factor authentication, and picking a random password for a user make cracking a password worthless for an attacker that has already had access to the database?

  • Sometimes the user database is the only database available to the attacker. Such is the typical case for SQLi on a login form. – schroeder Sep 21 '15 at 20:26
  • 2
    Consider an attacker who wants to log into a users account to perform actions on behalf of the user, such as transferring money via online bank. – puzzlepalace Sep 21 '15 at 20:28
  • Would that allow them to get past the two-factor authentication? Would they bother with a random password that is likely going to take years to crack? – DarkChowder Sep 21 '15 at 20:43
5

TL;DR: The answer is no. A user cannot be stopped from reusing the given random password on other sites, so a text based password will always have value to an attacker. This is true for all sites with usernames, and passwords.

Enforcing random passwords rarely works: it makes your users (customers ?) go away. Suggesting random passwords, and offering a generation tool, are good ideas, as long as they are not made compulsory. However, even if you succeed in enticing your users into using random-generated passwords for your site, you cannot prevent them from using the same passwords on another site. It can be expected that after having made the effort of remembering a random password, a substantial proportion of users will find it smart to reuse that effort, i.e. reuse the very same password elsewhere.

This is a very general property: as long as a user "knows" his password (and he must certainly know it in order to type it), then he can reuse that password in other systems that are outside of your reach. You cannot do anything about it, except trying to explain to users why this is not a good idea.


As for two-factor authentication: when it is there, it is for a reason, i.e. because one factor was not enough. If an attacker cracked a user password, then the user's two factors shrunk to one factor only. If one factor is not enough, then it is not enough. Or, said otherwise, if users authenticate with a password and a mobile phone, and cracking the password is not a problem, then why bother with passwords at all ? Just use the phone.

  • If the users device is stolen, or otherwise compromised, I don't believe they have much hope of keeping the password a secret. I'm not sure how many users encrypt hard-drives, and disable auto-complete, but I think it's a very low number. The other point though is something I did not consider, random passwords can be enforced, but that does not stop the user from reusing them on a different site. Which makes the security of both servers the lowest of the two. – DarkChowder Sep 21 '15 at 21:20
  • The user doesn't have to remember its password, her browser can. One can place a button to generate a password directly in the password input fields in the account creation webpage. The user will only see ***** and if she is used to the "remember my password" prompt from the browser, she might want to go with it. – Anonymous Coward Sep 30 '15 at 9:11
4

For at least two major reasons that come to mind immediately (no doubt there are more):

First, breaching a login info database for a web service isn't the same thing as actually logging into an account or accounts and using the service. For example, if I were to somehow breach Amazon's user authentication database (Which I'd never try to do, and which I'd never ever, ever possibly succeed in doing even if I tried.) that would be a very different thing from actually getting in and ordering things as someone else to my heart's content, or buying & watching movies online, or whatever. Similarly, as someone else mentioned you would want someone's bank site password so you could then log-in and perform some transaction that benefitted you, or copy down some secret financial payment info you could use to commit a financial fraud some other way, or do something along those lines. A password hash--or even a password itself--is just a pointless string of bits if it doesn't help you get access to something somewhere. And if you want to abuse someone's account to gain access to a given service, you need to un-hash their password hash back to the original to do so. And do so before the service realizes their user auth database has been breached and resets all the exposed passwords.

Second, human beings, in the aggregate, are pretty poor at using passwords properly. A lot of people--a small minority, relatively speaking, but still a lot of people in absolute terms--will choose incredibly weak/guessable passwords, as I'm sure you know. But an even larger minority will reuse passwords between different services & sites. And even reuse passwords between important services and sites vs. much less important services and sites. So, if a hacker breaches the user auth database for megastupidsportsaroundearth.com and gets (at the extreme) email addresses and cleartext passwords for a million people, it's a good bet thousands or even tens of thousands of those log-ins will also get you in the door at various banking sites, major online retailers, email services, etc, etc. around the net too. So even if megastupidsportsaroundearth.com invalidates all the passwords that were taken immediately after the breach occurs those email address and password combos will remain active at all the other sites where the user was using them. (Unless, maybe, your bank has a cybersecurity operation that is actively trawling the darknet for collections of stolen user credentials for its site and canceling them before bad guys can use them. But that's unlikely to save you even if your bank happens to be one of the minority who is doing such things so far.)

Password reuse with important accounts: just say no. :)

2

So one aspect that you did not mention but may be worthwhile. The attacker may only have a copy of the DB and not the live DB. In this case he/she would have access to the all the data up until he/she stole it but not ongoing. Having passwords would allow him to login legitimately and access the data. On this same line it could be used to cause damage, like cancelling orders, making false orders etc...

Most two factor implementations rely on a password and OTP, the OTP is usually resolved through a third party server, separate from the DB, so in this case the password may be compromised, if it resides on the DB, while the OTP would not. In fact OTP may be a good way to figure out if your DB was stolen, as you will start to see a lot of failed logins with the right password codes and wrong OTP.

Hope that helps.

  • Most two factor implementations rely on a pin and OTP, - I'm not sure about the "PIN" part. I think most require a password. Also, 2nd-factors may be a OTP or may be an action taken within an app (eg: hitting "Approve" on the Duo mobile app). Do you have stats to back up the "most" part of that sentence? – Neil Smithline Sep 21 '15 at 21:03
  • Your probably right, I always referred to it as PIN even when it was a password, but thinking of the acronym meaning number it is misleading. As far as stats, I am sure they are out there, but I pulled the most part from the vast majority of offerings out there are password and OTP and all the ones there they integrate with these types of applications do not typically use bio-metrics. Will edit the post for PIN though. – Brett Littrell Sep 21 '15 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.