“Your password should be committed to memory rather than using a password mgr”
twitter.com
twitter.com
On of my banks forces a 4-digit, number only password, that needs to be rotated every 90 days, with no consecutive numbers, can't repeat all passwords, no numbers repeated, and a few other conditions.
Heck, even random generated numbers will fail to get accepted sometimes (1671 has two ones. 1894 has two consecutive numbers. etc).
It starts to get really hard to pick new ones as time goes by and you've already used up lots of memorable patterns.
Hargreaves Lansdown, a UK broker big enough to hold people's pensions, asks you for eg the first, third and eighth letter of your password.
So not only no password manager but they are almost certainly storing my password in plain text.
They supplement this "security" by asking for a username in the format <name><2 digit number> and your date of birth...
When I worked in banking that type of policy would have been torn apart by any competent auditor, an internal audit at that.
If you're their customer or just concerned, write an email to the FSA, as certainly using a birth date as a username is phishy to the extreme.
The attacker just has to be successful against one of the combinations (eg characters 1+2+3), which doesn't offer enough combinations to make it a sufficient slow guess even if the password is randomly-chosen; for real user-chosen passwords it falls very quickly. Once the attacker has that it's trivial to leverage to guess other combinations (eg 1+2+4) repeatedly until you have the whole password.
If you have to implement a n-of-m password system, you can't do one-way hashing, so you have to fall back to keeping it encrypted in the database, and keeping the encryption keys separate and more strongly protected (eg in an HSM).
(But yes: n-of-m is generally a bad idea for usability as well as of very doubtful security benefit.)
Even if someone got the db, and managed to get the hash of a certain character combination, they'd need to get the exact one that the bank prompts for on the next login attempt.
"Users are more likely to forget complex passwords than simple ones. So in order to save resources on providing support to users of lost passwords, we force them to make their passwords relatively simple, and we can afford to do that because we have other more advanced mechanisms in place to secure accounts (secret questions, IP restrictions, log-in pattern heuristics, etc)"
Not that I agree with it. I still see no reason why they couldn't leave the choice of password complexity to the user. A complex password in addition to their "advanced" security mechanisms is always going to be more secure than a simple password in combination with these same mechanisms.
I suppose the real reason is probably something to do with not wanting to upgrade their "battle-tested" legacy systems that simply don't support complex passwords. Which I can sympathize with due to the risks involved in performing such upgrades.
Still, I imagine sooner or later their hands will be forced by a high profile data breach of some kind at a big-name bank that exploits the limited protection these simple passwords can provide.
This is their current password requirements: Password tips:
* Your password must include at least one letter, one number, and be 8-32 characters long. To make it stronger, include upper and lower case letters and special characters.
* Your password should be unique. Memorize it and do not disclose it to anyone else
* Avoid using names, dates or numbers tied to your identity (such as birthday, family name, pets, street)
* Use a password that differs from your other banking, email and social media accounts. Change it periodically, ideally every 90 days
The problem that some people are missing is that on most mobile platforms there are not restrictions to the clipboard, and virtually any application which is installed on the device can use it.
If the mobile platform would've supported clipboard isolation, or the application could plug into a password manager directly to retrieve the credentials that would be a completely different story. An "acceptable" alternative would be to implement an indirect clipboard in which a trusted keyboard application can replay the string for a short duration but that's not going to happen either.
The funny thing about password managers is that people claim they use them because they can't remember a complex password, while that's might be true but it also means that the password they use for the PWM is not complex enough to be used for say online banking in their minds which makes the fact that they use a PWM a bit ironic.
Whats worse is that probably most people who use a PWM on a mobile device choose to have a PIN lock on it after supplying the initial PW which reduces the PW complexity even further.
If you want to use a PWM on a mobile device i strongly suggest get some BT/NFC token based solution, while it's not the most secure one it's several orders of magnitude more secure than using a PWM on the common mobile platforms today.
Also as far as PW complexity goes while it's true that having a password like Password123 isn't a good idea, having something that looks like this isn't $qE`ADYCI=5% much better. There is an old XKCD comic about it and it's some what true that most randomly generated passwords are hard to remember but technically easier for a computer to brute force than a strong pass phrase.
If we are talking about hash braking then for example the following password melonyogurtstrawberry will take 2402661779222536 years 160 days 4 hours 58 minutes and 56 seconds to break (5.388571461264625e+29 password combinations), while the password $qE`ADYCI=5% will take only 167777774 years 185 days 20 hours 22 minutes and 17 seconds 3.7628372639504774e+22 password combinations). Both calculations are for an unslated SHA1 at 7000 Kh/s, and while taking into account the charset of both passwords so lcasealpha only for the 1st one, a mixedcase alpha numeric + all symbols for the 2nd one.
So while it might not seem like 3-4 random words form a more complicated password they do. Now before you go into dictionary attacks and say common words are easy to generate for a computer generating a string like melonyogurtstrawberry takes just as much time as generating something like $qE`ADYCI=5%, and while it's true that you might take just the most common words in the English language and do all possible combinations you are still left with 99955939123250 combinations if you take the 7000 most common words and use a 4 word pass phrase. And considering that most people have a vocabulary much greater than that with access to common "pop culture" words which are not part of the official English language the number of potential combinations is much much greater than that (which is good enough to begin with).
So yeah while it might not be popular to say using PWM's is not the most secure solution, the truth is that its not, at least not as how I've seen most people implement and use them.
I do use a PWM mostly because melonyogurtstrawberry still wont pass asinine password complexity calculators which look at the charset rather than the bitsize of the password. However i don't copy paste my passwords and i use a key file stored on a Token (Aladdin/Safenet eToken) to store the decryption key for the PWM DB.
On mobile phones i rather use long pass phrases which are easy enough to remember, i do add numbers and common substitutions to them tho which are not any harder to remember for me than 4 random words after couple of uses but are really not needed since even lower case alpha provides all the password complexity you can dream off if you reach 20+ chars.
No it doesn't; use a passphrase. Mine is a sentence I will never forget, but you're never going to guess/brute force it. You mention this yourself at the end. If only all (any?) web services would allow it.
Sorry but if you are trying to make a point that having all your passwords stored in 1 place is better than memorizing good passwords it's wrong.
Also, like I said, most services will not allow me to use a common pass phrase because they all have different restrictions. Too long! Must include a special character! Can't include a special character!
> An "acceptable" alternative would be to implement an indirect clipboard in which a trusted keyboard application can replay the string for a short duration but that's not going to happen either.
Actually Keepass2Android does just that - it provides an (optional) dedicated keyboard layout that you can install and activate.
> Whats worse is that probably most people who use a PWM on a mobile device choose to have a PIN lock on it after supplying the initial PW which reduces the PW complexity even further.
Some password managers have the option for using a part of your password after the database is unlocked - you get a limited number of tries (configurable) and the database locks if you don't guess the short code.
I use Keepass with an eToken on my PC, found too many things about the Android version if it that i don't like :)
As for the PIN part, most people will setup a 4 or 5 digit pin, you would be surprised how many PIN locks can be broken with using the 10 most common PIN's avoiding most lockouts. If you have the device it self then avoiding the PIN lockout is a trivial thing to begin with. IF you talk about the Keepass2Android then it has many issues including not encrypting the the DEK in memory while being active, caching way too much shit on disk, and overall having quite questionable other implementations so there's a good chance you won't have to brute force anything.
One response to this is to use Kerckhoffs's principle
https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
and say that to estimate the entropy of a password, we should assume that the attacker can guess the "system" or method that we used to generate it, but doesn't know the true physical randomness that went into it. (If we seed a random number generator with the time, the attacker can know that fact and try every possible seed value as part of the attack.)
Another response is to say that the attacker doesn't inherently know the system but that the attacker's reasonable attempts to guess it still need to be part of the entropy calculation, because a prudent attacker would have some model of plausible and likely password generation methods that would inform the order in which the attacker tries guesses. So if the attacker decides "next, I'll try all sequences of three English words", you just have to figure out at what point the attacker is going to try that rule as part of the guessing process, and that lets you figure out when the attacker will succeed, which in this case is still incredibly much sooner than trying all strings in shortlex order.
I think the former method, the assumption that the adversary knows which password generation system you're going to use, is safer, for basically the reasons that proponents of Kerckhoffs's rule have given. Here it's that if we don't truly know how much uncertainty the adversary has about our method for generating passwords, it would be safest to assume the uncertainty is zero, and that all the strength comes from the randomness we fed into the system. By that measure the strength of your passwords is exactly n log₂(|d|) when you use n words randomly, independently, and uniformly selected from a dictionary d (maybe assuming that the passwords you create that way don't overlap with passwords that could have been produced by some other simpler rule that a realistic adversary would have regarded as worth testing sooner).
But, since when are password managers best practice? I wouldn't want to put all my eggs in one basket...
It took me more than fifteen but less than twenty years to develop the ability to commit dozens of complex passwords to memory and change them frequently enough. I highly recommend that you develop this ability, too. Practice, practice.
While the benefits are clear, this seems a tad unreasonable to ask users to do.
My pass store currently has over 300 passwords. Some of which I've not used in ~1year. Good luck remembering that.
I'll accept these downvotes as a badge of honor!
Do password managers have a history of being cracked (via keylogger if nothing else)? Of course this used to happen to browsers (which didn't used to even have a "master password").
I've personally fallen victim to malware that would automatically extract your password from the "remember password" feature of AOL Instant Messenger. Now, I never use that feature in any application. (I also never deliberately run malware anymore, except in a clean-install.)