This is an unfortunate problem with a lot of online banking systems. The bank I use doesn't even let me use special characters in my passwords, or passwords longer than 16 characters. It's a shame that the one online system that should be the most secure has a password policy worse than a browser game...
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.
A bank I once used had the online banking system tied to the card's PIN. Change the PIN, online banking password has changed. Change the online banking password and card PIN is changed. And yes, the password/PIN was limited to 6 numerical digits.
Why would you want a complex password for a bank in the first place? The only reason that would be necessary is if the bank had hopelessly woeful security and there was a risk of their encrypted passwords being stolen.
There's a difference between non-complex and guessable. You don't need to have a 16+ character password to make it non guessable. My comment was referring to brute forcing rather than guessing...
All the restrictions banks give don't make the password less guessable. Lots of people can still use their birth year, or their postal code. Banks are mainly a PITA, not really "securer".
Sadly it's not but it's also doesn't mean that they store you PW in plain text. Verified by Visa or 3Dsecure uses a similar scheme, they has the passwords however they chop them single chars and use a salt which is derived from your PAN.
It is not necessarily a sign of storing passwords in plaintext. They might have as well prepared several combinations of different letters from your password and then hashed each combination separately.
It turns out storing hashed combinations is barely any stronger than plaintext.
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.)
Hashing isn't to avoid someone guessing, but to avoid leaking thousands of passwords when you db get stolen.
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.
I vaguely remember hearing this line of reasoning behind Banks and their password complexity restrictions:
"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.
Previously, TD online passwords were only a maximum of eight characters and you were not allowed special characters. Also, I heard that letters were case insensitive.
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
Write your username/password combos on paper, in a code that is contained in your will if you don't trust those who could access it. Your next of kin will thank you.
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.
> 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.
Apple doesn't allow replacement keyboards AFAIK considering that what was the post about.
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.
>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.
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.
The use pass phrases for all passwords? use word/story association to remember them, if additional complexity is needed use common substitution camel casing etc.
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.
My point is that it is completely and obviously impractical to expect people to remember a large number of complex passwords, so it's a moot point. I mean, seriously; you can't actually believe that is a sane option.
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!
It's worth noting that the password entropy should be estimated relative to the attacker's uncertainty about the password. An attacker, even a brute force attacker, is implicitly assigning a probability distribution or at least a probability ranking to candidate passwords: the attacker can choose what order to guess them in and isn't constrained to use "the shortlex ordering of all strings" as the search strategy.
One response to this is to use Kerckhoffs's 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).
Granted, the UI should allow paste and the password policy should allow complex passwords.
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.
You just can't expect the average user to go to such lengths. Password managers may not be perfect, but they are still an improvement over existing methods. This is incredibly useful when you're testing out a lot of online applications or apps that you may not ever use again - there's no way to have unique passwords for all of them without a password manager.
Sure, we can all remember the top 5 used passwords. Some of use can remember 10. Other 30. But there's not a chance in hell I remember every single password.
My pass store currently has over 300 passwords. Some of which I've not used in ~1year. Good luck remembering that.
Most replies here don't address the core question. The one that does suggests that password managers are second-best, not best practice.
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.)
