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?

closed as primarily opinion-based by TheJulyPlot, Serge Ballesta, Xander, Robert Mennell, Dmitry Grigoryev Jun 13 '17 at 15:25

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 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 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
  • 6
    Opinion questions are off-topic. I'm also not sure what your question really is. – schroeder Jun 12 '17 at 18:48
  • 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. – Dominic Lipscombe 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
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

  • 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
  • 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. – jpmc26 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; 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
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?

  • 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 ;) – peufeu Jun 13 '17 at 2:32
  • @peufeu xkcd.com/936 – a CVn Jun 13 '17 at 8:46
  • 1
    English can be said to have about 228,000 words. 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? – a CVn Jun 13 '17 at 8:51
  • 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... – peufeu Jun 13 '17 at 15:51
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.

  • 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) – Dominic Lipscombe Jun 13 '17 at 0: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. – Dominic Lipscombe Jun 13 '17 at 0:42
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.

  • 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 – Dominic Lipscombe 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 8: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. – Dominic Lipscombe Jun 13 '17 at 9: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

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