12

I am now onto the stage of developing the back end system, where we are able to view/modify all client information, their customer information, and so forth.

I am looking into requiring the use of two-factor auth via Authentication Apps (NOT SMS) (already implemented), and if this is unavailable, requiring the use of a very, very strong password and limiting it to a certain amount of days before it needs changing, plus blocking most common passwords.

I have a number of "common password lists", obtained from a Github repo, found here: https://github.com/danielmiessler/SecLists/tree/master/Passwords.

I am looking at using the 100,000 password list as I believe it offers the best without going too far, but I need your opinions on if you'd use the 1/10k or million list.

Finally, looking ahead, I am looking at only allowing full access to data if the account is logged in via a company vpn, and if not, give them a dumbed-down version which doesn't let them go quite in depth.

When it comes to auto generating a secure password for the user using some kind of JS/Backend script, I don't think these are ever the answer. This is because, they are not going to remember the password, only save it into their browser. The minute they attempt to login somewhere where their password isn't saved, you can guarantee their account will receive a reset password request. This can result in a dropped use for that session, or if it gets too much for them, a lack of use for the entire account for the foreseeable.

For staff at this level, I have also disabled the option of email based password reset and require that they do it internally, to ensure that weeks of security implementations and hours of explaining that my Sec SE thread isn't off topic doesn't go to waste over a password to an email address set 10 years ago.

The information that our own staff can view includes ALL customer information AND their customer information like full contact details, full home address, bank account sort code/account number, the ability to charge their card (we don't store their CC info, just a PP/Stripe Key) even down to spending habits, plus other bits.

What are your ideas on implementing the strongest possible way that a user's account of this level can be secured, not just through passwords but other means, without annoying the user?

XLR
  • 149
  • 1
  • 8
  • 6
    Opinion questions are off-topic. I'm also not sure what your question really is. – schroeder Jun 12 '17 at 18:48
  • 5
    I can only add one small detail to iain's excellent answer: The best way to support users in choosing strong passwords is to enable random passphrases with a sufficient wordcount and dictionary size, such as those that can be generated with [Niceware](https://www.npmjs.com/package/niceware) or similar. It's user-friendly to keep them all lower case for ease of typing, because the password entropy comes from the dictionary keyspace, not from complexity requirements. – Royce Williams Jun 12 '17 at 17:22
  • The problem is you're asking for "Is this password scheme secure enough?" which is asking for an opinion. Opinion questions are off topic. In fact this question has been asked MANY times before. Please use the search box to find questions like this that already have definitive answers. – Robert Mennell Jun 12 '17 at 22:52
  • @RobertMennell I couldn't find anything for what I was asking, as they all appear to be about password length and encryption. This is about the user securing their account in the best way possible due the amount and level of data available, without reducing the user-friendliness. Thanks, though. Maybe I should update the title. – XLR Jun 12 '17 at 23:17
  • Does your own staff *need* plaintext access to all the customer data? You will get much better _customer_ security by limiting your own internal staff's access to the data, to only those we need to see the data. Encryption of customer data at rest, with only authorized, audited, access by *your* employees will be the next low hanging fruit if you want additional effective technical controls. – JesseM Jun 12 '17 at 23:18
  • @JesseM Access WILL be level based, but some will need it yeah (I.E: Account Managers for 'bigger' customers). I am considering encryption in the future, but not at the minute. No staff with the exception of any future DBA will be able to touch the database, and that is locked down anyway (externally hosted, IP Firewalled, User Whitelisted, etc.). The only problem is **you're only as secure as your weakest password**. – XLR Jun 12 '17 at 23:26
  • Basically you're asking "what makes a good password". – Robert Mennell Jun 13 '17 at 00:13
  • @RobertMennell No, I'm not. I'm asking what's the best way to secure an account that holds so much data. Maybe I wasn't clear enough. Oh well. – XLR Jun 13 '17 at 00:22
  • If they have MFA and email based recovery whats left? Encryption and best practices. So guess I over simplified(sorry), but youre asking what the best practices are, yes? – Robert Mennell Jun 13 '17 at 00:29
  • @RobertMennell to be honest, that's a very good question. Best practises in terms of not just PW's, but everything that a user themself can control as well. For staff at this level, I've actually disabled the possibility of email based password reset and made it so its only possible internally, just in case an email address has been compromised. It would be silly to go through all this and then get massively rear ended because of a password to a staff's email account set years ago. – XLR Jun 13 '17 at 00:52
  • The tagline change makes this question a little more understandable – Robert Mennell Jun 13 '17 at 01:14
  • keep ratcheting down until your help desk is working hard but is not overwhelmed. – dandavis Jun 13 '17 at 14:28
  • @dandavis At the moment there is no help desk and it's the start of a brand 1 man band project! Start as you mean to go on, though. – XLR Jun 13 '17 at 15:29

4 Answers4

26

You need to balance security with usability.

The latest NIST guidelines on passwords say that you should not enforce periodic password changes for the sake of it and you should not impose excessive password complexity rules. The guide suggests they can result in passwords that are actually less secure, you can read a summary here NIST password summary

It does suggest that preventing the most common passwords is best practice and for that my impression is that the top 100,000 should be good enough, I think the top million is excessive. users will become frustrated if they get to the 4000th password attempt when trying to register.

this nice infographic from Intel shows why length is more important than complexityIntel password infographic

Two factor authentication definitely improves security but be aware of current thinking around using SMS due to insecurities in the SS7 routing protocols and consider alternatives like authenticator apps ARS Technica 2FA/SS7

iainpb
  • 4,142
  • 2
  • 16
  • 35
  • I've updated the question a bit. We do use Authenticator methods as opposed to SMS, personally I don't think sending an SMS is a great way of doing it, and although minimal, it does cost us per sms which is obviously not ideal. I am also considering the option of forcing a log out every 25 minutes but not destroying the session, so that we keep the the TFA authorisation alive to stop them constantly having to re-auth via TFA. Usually I never ever go this far but the data that this system holds on people is too personal to not explore every avenue and get a second mind onto it. – XLR Jun 12 '17 at 16:48
  • 8
    "I think the top million is excessive. users will become frustrated if they get to the 4000th password attempt when trying to register" Huh? Are you suggesting that users _should_ be allowed to use one of the top 1M most common passwords merely because they might get frustrated after repeatedly trying to set one of those as their password? That's ridiculously insecure; even a 4-character random alphanumeric password has more entropy than that. The limiting factor for disallowing common passwords is memory/storage resources; not user convenience. – Ajedi32 Jun 12 '17 at 18:17
  • 1
    That is not what my answer says. With a proper minimum length requirement in place you exclude many of the most insecure passwords. You have to have a stopping point for your list of exclusions, your own security and UX requirements determine if that list is a thousand, a million or a billion. – iainpb Jun 12 '17 at 18:27
  • For the sake of also not having to run a query on an 1,000,000+++ row table simply to change a password (as the table also contains other banned strings such as email providers, mobile numbers, etc.), I've gone with the 100K. The Speed/Security trade off here is due to the fact that obviously the staff will get told to not have a stupid password. I'm also (for the future) considering only giving full access to the data for people logging in via a company VPN, otherwise giving very limited data. – XLR Jun 12 '17 at 19:46
  • 10
    @iain I agree that you have to stop somewhere. My point is just that, while there may indeed be valid reasons to stop at 100k (such as the hard disk/memory limitations of storing that many passwords), "users will become frustrated if they get to the 4000th password attempt when trying to register" is most certainly not one of them. If your users are making multiple attempts to choose a password for themselves that's in the list of 1M most common passwords; they've got bigger problems than "you're not allowed to use this password" errors. – Ajedi32 Jun 12 '17 at 19:56
  • 6
    +1 for invoking [AviD's Rule of Usability](https://security.stackexchange.com/a/6116/46979). – jpmc26 Jun 12 '17 at 20:07
  • @Ajedi32 the only problem is, you do also have to balance it for the 'average man' because when it hits the point that its annoying the user, there is a high chance they'll just forget it altogether which can end up in an account still possibly being unsecure, or an unfinished registration. Saying that though, this is for a back room system so we wouldn't have the latter issue. – XLR Jun 12 '17 at 20:07
  • 8
    @DomLip I'd agree if we were talking about overly complex password requirements or an onerous password expiration policy, but "your password cannot be in the top 1M (or even 10M) passwords" is neither of those. Even a password in the top 10M [is easier to crack than a random 4-character alphanumeric password](https://www.wolframalpha.com/input/?i=10+Million+%2F+(26*2%2B10)%5E4); and almost no one would consider "password length must be > 4" to be an overly burdensome security requirement. – Ajedi32 Jun 12 '17 at 20:25
  • @Ajedi32 I have a problem with using entropy to equate usability. Users can easily generate a 12 character password, but *by definition* of "top 1 million passwords", there's a pretty good chance that they will pick one. If I had a system that required a "not top 1 million passwords", I'd also suggest including a "Generate my password" function in the app, maybe only showing it after they've hit the restricted list a time or two. It would need to generate something like XKCD style, since the user has demonstrated they aren't savy and would probably have trouble with a long random password. – jpmc26 Jun 12 '17 at 21:01
  • 1
    @jpmc26 To be honest, I don't think an automatically generated password is user friendly at all. They've shown they can't make a decent password, so the minute they try to login from somewhere else (that the browser hasn't got the password saved), you can be 100% sure that their account will be getting a forget password request, which again can result in either a single session or complete drop of use if it gets too much for them. – XLR Jun 12 '17 at 21:05
  • @DomLip True. It really depends on your particular use case and how much you can afford to annoy users vs. the cost of a successful attack. =) But I think it's a compromise worth considering, even if it doesn't ultimately fit your use case. Maybe at a bare minimum, end users should be *warned* if their password is extraordinarily weak? If your system is internal and used primarily by employees or something or handles sensitive data or permissions, you can definitely afford to be a little more annoying. There's no perfect security, only ways to mitigate types of attacks. – jpmc26 Jun 12 '17 at 21:08
4

From my experience passphrases are a lot easier to remember than passwords, and not that slower to type. I mean, the standard recommended password requires several digits plus diacritic marks, which means your fingers have to juggle the shift key and be all over the keyboard. A simple sentence in your native language will usually be just as fast to type, and much easier on the brain.

Open a novel at a random page, or use a random phrase generator like this one.

It gave me "Have the cops found you yet?"

This has one capitalized letter, one "?", is easy and fun to remember, and is long enough to thwart the NSA. And it is much more secure than the user's birthday. Easy to remember, hard to guess.

Plus, if you're a non-English speaker like me, then it opens plenty of opportunities to slip in words in your native language which are unlikely to be featured in a dictionary attack. Can you spell a sandwich in Russian?

bobflux
  • 236
  • 1
  • 3
  • About 40 bits of entropy. Decently resistant to online attacks, but virtually no protection against offline attacks. – Mark Jun 12 '17 at 23:16
  • Add a few easy to remember speling mistakes ;) – bobflux Jun 13 '17 at 02:32
  • @peufeu https://xkcd.com/936/ – user Jun 13 '17 at 08:46
  • 1
    [English can be said to have about 228,000 words.](https://en.oxforddictionaries.com/explore/how-many-words-are-there-in-the-english-language) That works out to, in the best of cases, 17.8 bits of entropy per word. But your password doesn't contain words chosen at random; the words form a sentence, which *dramatically* reduces the entropy. For example, there are only a few words that are likely to follow the word `found` in a gramatically correct sentence. And what makes you think the NSA doesn't have every book they can get their hands on OCR'd and stored as input to their password cracker? – user Jun 13 '17 at 08:51
  • Hence, I wouldn't be surprised if Mark's estimate of 40 bits of entropy is reasonably accurate. And if your threat model includes the NSA, then remember what Snowden said in 2013-ish: assume your adversary can attempt a trillion password guesses per second for a PGP secret key passphrase. That's about 2^40 per second, deliberately slowed down to reduce the rate of a brute force search on the passphrase. Is it likely that they can do *worse* today than some four years ago? – user Jun 13 '17 at 08:53
  • I have added a word list of nearly 500k Words to a DB Table as I was looking at doing something like mentioned in this answer. However, due to the fact that this information is readily available (I got it off GitHub, but there's also a file in your Usr directory with every word) I have my doubts that this would be a reliable method. This is into database leaked territory really and if you've got that far you've got all the time in the world and probably even a decent botnet to do the guessing for you. – XLR Jun 13 '17 at 10:07
  • 1
    Another variant is to pick the first syllables or first 2-3 letters of the words in an easy to remember sentence. Anyway, I was recently baffled by the BitKeeper harddisk encryption tool: its new version switched from a passphrase to ... a numerical PIN! Both harder to remember, and easier to crack... – bobflux Jun 13 '17 at 15:51
2

To address your question "What are your ideas on implementing the strongest possible way that a user's account of this level can be secured, not just through passwords but other means, without annoying the user?"

A common practice I'm aware of that is "excessive" is the practice of locking out accounts after X amount of failed attempts. This is to prevent brute force attacks. At first glance, this seems sensible, but consider the following:

  • Lists of user names are relatively easy to get hold of, or guess.
  • The number of failed attempts causing lockout is generally quite small. (10 or less)
  • Logging in as a user from a remote device is common.

When you put these together, a company could be brought to its knees by a malicious script remotely logging in as every user or a large subset of users multiple times, locking out all the accounts. To avoid this, simply throttle the number of attempts from a given location to 1 every X seconds after N attempts. Brute force attacks rely on many guesses in a very short timeframe. If a Brute force attack can only attempt 1 attack every 5 or 30 seconds, rather than thousands per second, the brute force route becomes impractical.

This can be annoying to users because they need to call someone to have their account unlocked, yet actually can be used as a security flaw. In addition to adding a way for a malicious code to lock everyone out, it can also cause the key-holders to become desensitized to people calling to have accounts unlocked. This can lead to more advanced social engineering attacks.

For Example: IT guy: "This is the third time this week!"
Malicious attacker: "Yeah, I just can't remember my password! Could you reset it to ..."

Edited to show how it answers the question.

Drigan
  • 139
  • 3
  • This is a back end system, although it will be web accessible so it could still have this caveat if it was to be implemented. I have no plans to for exactly this reason, plus log ins are also processed via AJAX so once the user has a CSRF token it would be trivial for them to create a script to run it hundreds of times (For most of the site the CSRF is per-page-load, but login doesn't due to possible incorrect attempts rendering it void). One workable method of this could be locking out/captcha that specific IP/Session for X minutes, and could even go as far as using something like evercookie – XLR Jun 12 '17 at 19:31
  • 2
    Your answer doesn't really answer the question. You point out a flaw in how some rate-limiting systems are implemented, but while this may be important it has nothing to do with password strength/security. – Micheal Johnson Jun 12 '17 at 21:15
  • 1
    @DomLip in that case, I challenge your use of the term "back end" if you an access it directly from the web - this one fact alone changes the threats to the system – schroeder Jun 13 '17 at 08:05
  • @schroeder back end as in back room... our company's staff. And to be honest, the security to accounts shouldn't be reduced in any way even if it is internal only accessible. In my opinion, to maximise protection, the system should always be treated as if it's front facing when it comes to security in my opinion. – XLR Jun 13 '17 at 09:56
  • @MichealJohnson: this has everything to do with password security. If users are frequently locked out, the passwords need reset/unlocked. Frequent resets/unlocks lead to psychological holes in the practical security of a system. I probably should have made the point more explicitly, but it was pretty easy to extrapolate. – Drigan Jun 13 '17 at 20:33
  • @Jedi: You may need to check what you wrote. You said "Provide answers that don't directly address the question." Also, your link has nothing to do with anything as far as I can tell. Maybe that was your point? – Drigan Jun 13 '17 at 20:38
2

Building a secure system isn't just about password length. What you can and should do depends on who your users are and how much control over their actions you can require.

This may seem counter-intuitive especially after reading the rest of my answer, but if users don't work for your company and are only accessing and managing their own data, put only minimal requirements on them. If they want to have an insecure password for their own data, you shouldn't stop them. You can warn them and provide options for them, and even suggest things to them, but don't stop them from protecting their data how they want to.

That being said, DO at least give them enough options to protect their data if they want to. (My biggest security pet peeve is having a site set a password length limit less than 32 characters. e.g. password must be between 8 and 12 characters.)

On the other hand, if they work for you, and they are managing other's data, (and it seems like this is at least partially the case since you mentioned staff have broader access) then there are plenty of things you can do.

Keeping in mind that most of this only applies to the latter case where people work for your company, here are my suggestions:

  1. For a very secure system, definitely require 2 factor authentication of some kind. For a web interface you can require client certificates (on smart cards or similar) for authentication in addition to passwords. This means that a user must have something and know something. You can also use any of the token generators (hardware or software) for a similar level of security, but this usually requires the user to enter something different every time, whereas the certificate method can simply take place as long as the user has their smart card (protected with a static pin of course).

  2. Log out a session after inactivity. Don't just log people out if they're still doing things. Log them out if they haven't been doing things for like 5 minutes.

  3. Require the use of client side encrypted password generators like KeePass or LastPass so that you can effectively require passwords that are 64 characters or longer. Since these are stored on a user's machine and encrypted with their own password, it makes the weakest authentication take place between a user and their own machine. The internet facing portion of the authentication uses a much more secure password and prevents password reuse problems. (Password reuse is your biggest enemy here)

  4. Require the VPN always. This may sound overzealous, but I've seen far too many web developers who don't have an inkling of security knowledge, and it doesn't take long before their code is exploited. If however all your web stuff is done over a VPN (for employees at least), then those who shouldn't have access never even see the login screen, insecure or not. (This is not a license to write insecure code)

  5. Hire a security expert. And if your budget allows it, a whole team. Because you can't think of everything, and having somebody specializing in security look at your systems is probably the best idea I can give you. Make sure they do a good amount of penetration testing.

The main idea behind system security is to know your threat model (with user's bank account info stored, you have a REALLY high level threat model), and defense in depth. Put as many layers between your systems and your nemeses as possible without sacrificing too much convenience for your legitimate users.

Final thoughts: Training your employees to use secure practices isn't too much to ask of them. Passwords aren't just about length and complexity. Password reuse is one of the hairiest problems we face, and one of the biggest reasons to use 2fa. I'd be willing to bet that many employees of yours use the same password for work that they do for other services. Those services don't have the same threat model, and don't guard their systems as judiciously.

Andrew Hendrix
  • 84
  • 6
  • This, Andrew, is a f'ing great answer. The only problem I've got with staff using extra extra extra long passwords is unless they're genuinely memorable, they're counter productive. The same goes if they're stored on one specific system. The bank information isn't highly sensitive due it only being a SC/AC and there isn't much you can do bar put money in and set up a Direct Debit, but we still have them encrypted using a special token (which changes whenever users update their personal info, so updates all info encrypted with this key). The VPN isn't something I've got set up yet, but it (1/2) – XLR Jun 13 '17 at 00:38
  • definitely seems like something I'm going to implement, simply because it stops all the crap that comes with unsecured accounts. Even tho its still in development I'm looking at the logs and seeing random servers loading the login page. I'm looking at expiring the session at a max of 25-30 minutes, but can be set less by the user if they so wish.I want to put them in charge **up to a point**,so they feel in control, and they know why its doing it.As you can tell, the data is highly sensitive data which would result in ridiculous fines from the ICO if breached, so I'm doing as much as possible. – XLR Jun 13 '17 at 00:42