They probably hired the same security consultant as my bank, which requires your online password to be exactly six characters long. My hypothesis is that this is a technical limitation due to the password being stored as a char(6) in their database.
Same goes for Virgin Mobile (at least here in Australia), which ALSO requires you to only use numbers. Last week they forced me to change my password due to an "important change" - ascending or descending numbers were not allowed anymore. I guess they had a look at their plain text password database and realized that 99% of their users used 123456.
Purely a guess but I think they only allow for numbers because it's a phone company. If they intend for people to enter their password/pin on their mobile phone then limiting it to only digits that you can type from any phone is understandable. Now I'm not saying it's a good idea but at least there is some sense to it.
In no particular order my usual gripes with passwords and auth in general are:
* Disabling clipboard copy/paste (because now I can't use my password manager)
* Length limitations (anything less than 32 characters is a a limitation)
* Requiring punctuation or "special characters" (they're annoying and don't add real security ... just use a longer password)
* Lack of two-factor (preferably TOTP)
The password limit is really the scariest one. Short passwords are much easier to crack. Also, I have a sinking feeling that every site that says a password must be a specific max length is storing it in plaintext. Otherwise why the heck would it matter what the length is?
Huh. I never actually did the math before, but: there's 32 symbols on my (US) keyboard. Upper+lower+number gives a baseline 62 characters. This gives us a password space for brute force attacks of
10 char alphanum: 62^10, or 8.4e17
10 char alnumsym: 94^10, or 5.4e19
11 char alphanum: 62^11, or 5.2e19
One extra character instead of needing to type symbols into my phone, with nearly identical complexity? Sounds good to me.
I have Virgin Mobile in the US (it's one of the cheapest options with good quality phones), and it seems the same. It made me set a 6-digit PIN as my password, and my phone number is my username. Here are the requirements listed on their website:
Your Account PIN must be:
-6 numbers (no letters or special characters)
-no more than 3 identical numbers in a row (222)
-no more than 3 sequential numbers (such as 234)
If I did the math right, that's approximately 900,000 possible passwords, which is obviously really low
Is rate limiting by IP the best way to handle something like this (other than the obvious, allowing better passwords)? You could obviously rate limit by account, but then you make it easy for anyone to lock anyone else out of their account. And obviously rate limiting by cookies as mentioned is awful.
This is funny because these restrictions reduce the total number of possibilities. I get that the idea was to stop commonly used passwords, but that's what they should have done - disallowed the top N common ones.
No, it could have just been random. They've reduced their keyspace massively by doing that. Six characters, all numbers, no ascending or descending. 123849 is invalid as an example, as is 954391.
Massively? For every 3 digits you look at, they're only blocking about 26 out of 1000 possible values. Factor in that there are 4 starting points to apply the restriction to, and you get roughly 10% of passwords being blocked. That's only a sixth of a bit of entropy being lost. Barely anything.
so 741963 would pass? Not sure how that rule your stated actually functions, I am probably over thinking it.
I am curious what simple pattern people will adapt to once you eliminate simple sequences. It has got to be predictable, as in someone could put math behind it.
Any run of three characters in sequence, forward or reverse, is marked as invalid. 123 876 432 would all mark the whole password as invalid, even if they only take up half the string. Yours would pass though, yes.
His is two vertical runs along the keypad. The forbidden ones are horizontal runs. That's why it's stupid. Any modeling of passwords humans would generate for use on a keypad should forbid 741 by the same logic that forbids 123.
My guess (with nothing to back it up) is people will start moving into paterns of 963 852 741 or the reverse since they're easy to type on the numpad without really remembering the values.
edit: On second look, that's exactly what you did in your example.
6 characters for a bank password?! Get a better bank!
It's unbelievable how bad the password policies of some banks are. Mine doesn't allow special characters, for example. Fortunately it does allow longer passwords at least.
That's nothing, mine's a 5 digit pin code which they only validate 3 of in a random order (to annoy keyloggers, I assume) plus the last 4 digits of my phone number.
Edit: This feels like the scene where Mel Gibson and Rene Russo compare scars in Lethal Weapon 3.
Bingo. I wonder what their brute force protection is like, but I'm not going to go pentesting the login of a company I'm in the same legal jurisdiction as.
Yeah, similarly, Lloyds/HBOS in the UK do allow you to have a master password but you also need to fill out a "memorable information" where you select 3 random characters from a second password. But you don't type them, you select them from a drop down. I can see how this would annoy the most basic of keyloggers but it is also a UX disaster and not suitable for decent loggers. Pisses me off.
My bank not only allows a maximum of 6 characters, but it truncates all characters beyond 6 when processing the login form. If my password was "passwd", they would accept "passwdjdodw89wawlks".
My bank secretly truncates your password to the first 12 characters. The login form processes all characters. I found this out because I couldn't login after having "successfully" set my password to 32 random characters. Luckily customer support was able to confirm the first 12 characters of the password over the phone.
At least you have to enter the code in a virtual numpad that is randomized after each connection on their webpage.
I guess they settled for this measure so it does not annoy their less "tech-savvy" customers. I am baffled to see banks working with such low security practices in general ("admin"-like access on your bank accounts by any employee, checking money transfers AFTER executing it,...).
One bank that I'm not going to identify is particularly scary. Predictable account number (sequential, I think) + 4 digit PIN. Even if they lock individual accounts after X retries, nothing prevents a well-distributed botnet from gaining access to an account (on average) every 10,000 attempts.
There was a recent post analyzing the distribution of 4 digit PINs, and using that I think it was something like 20 guesses would give you a 10% chance of access.
Financial company I use apparently shares the same password between their web site and their automated phone system. So in addition to a max length of 10 or 12, you can't use anything non-alphanumeric since you wouldn't be able to enter it with a phone keypad.
Also rules out stored a hashed password, too. Terrible idea all around. (Edit: ok, I guess they could convert the PW to the phone key version when initially setting the PW, and then store both the hashed text PW and hashed phone key PW. So not "rules out". I just doubt they do it.)
Even if they do, acquiring both of these hashes vastly helps with brute-forcing: you first break the phone key password and then check only the alphanumeric passwords that match it against the alphanumeric password's hash.
> My hypothesis is that this is a technical limitation due to the password being stored as a char(6) in their database.
and legacy security policies/requirements that have not undergone any update.
I've worked on a project that touched banking passwords in the past and in a push for modern password requirements (which was met....somewhere in the middle), the response was that since the number of attempts was so restricted (and claims about whatever security/fraud engine they were using), the risk caused by the restrictive passwords were essentially negated.
From a security perspective, how true is this? I'm genuinely looking to be educated. It did seem like a reasonable measure to prevent a bruteforce attack, but I'm not sure if I'm missing anything
Sure, it's secure from a front-door perspective. But if say, a future unpatched software vulnerability leads to the password hashes being leaked (a when, not an if) the 6 letter password hashes are going to be mighty easy to crack.
Actually, having weird password requirements might make them, on average, more secure.
Why? Because the passwords will be different.
The average person uses the same password over many sites. The chances of one of those sites being hacked/rogue is 100x higher than the bank getting hit. Weird requirements = different password = more secure.
A common way of expressing what Afforess said is that simple passwords with effective rate limiting offer "brittle" security. As long as everything works perfectly, it's safe. However, there are many failure modes that rapidly degrade to trivially having access to all accounts. One would prefer to have defense in depth, such that failure of one part of the system would yield a system in which it's easier, but not trivial, for an attacker to access accounts.
Using a modern Key Derivation Function (KDF) such a Scrypt along with allowing more complex passwords would in many cases prevent attackers from accessing those accounts that used more complex passwords (or force the attackers to change the passwords on the accounts, risking discovery when the owners next try to log in). Enforcing minimum password complexity would dramatically increase the percentage of accounts that couldn't be bruit forced if hashes were stolen.
Hopefully the answers to security questions aren't kept in the same database as the password hashes, since they're nearly password equivalent. Even if the security question answers are hashed, 99.9% of the answers can be easily bruit forced. I grew up on g1SUIt2FJr1IHI Street and my first grade teacher was Mrs. IvwiYZ4Oar9uZg. Last year my dog was named AuiwVvMSPNTWbgy and this year I renamed him to dBuSHCTJDuSdAUu, but few people are so lucky. Also, when calling up my bank for help, it sure sounds like the phone operator can read my secret question answers off of the screen. In any case, an attacker takes some risk of discovery by resetting someone's password and hopefully banks all watch for spikes in rate of password resets, but secret question answers are nearly password-equivalent and seem to almost always be stored in plain text. The secret questions answers are the keys to the kingdom and the amount of code that has access to them needs to really be minimized and audited extremely well.
I would be very interested to hear a first-hand account from the developer who gets the requirements and has to actually build in these types of password restrictions. Did you object? Does anyone recognize how absurd it is?
Better than idiotic websites that enforce their character length limit on the client, but not on all pages on the client. So you can change your password to 123456789, but the login page will truncate it to 12345678
Strange. I tried just this morning before posting but I will update my password and try again.
edit: after updating my password it's now case sensitive, and allows special chars. As the sibling comment suggests, it looks like they have two different authentication routes and updating your password moves you onto the newer one.
I tried it with a new password today. The requirements were between 8 an 32 characters and some special characters allowed.
I just tried with all lower case letters and it rejected it. Prior to changing my password however, I experienced everything you described. They must have 2 systems and setting a new password must switch you to the new system. Can't fathom why they don't just mandate everyone changing their passwords.
I didn't know they changed their policy, so thanks :). Their old policy stripped out capital letters too which made it even less secure. Sadly it still doesn't allow all special characters, but it's a start.
My bank enforces a six character limit and the passwords aren't even case sensitive. But, brace yourself to feel safe - they make me answer a security question (in this case, "What high school did you go to?"
They made a (record) four billion dollar profit last year, so this strikes me as security designed by someone with an MBA and a spreadsheet. I'd be upset, but, I've been stupid enough to keep doing business with them...
I believe this is to allow alternate inputs of data, like "fill in the 2nd, 5th and 6th character" or special keyboards in ATMs, like "Press the arrow that contains the 1st letter of your password"
Very likely to be a legacy back-end system. Doesn't excuse it at all, but that's one I've seen limit banking systems in the past either in password length, complexity or case sensitivity (I've seen some systems automatically upcase passwords without telling you 'cause the back-end is case insensitive)
That could well be it. My bank enforces similar short passwords, but they're not such a big security risk since they lock the account after three mistakes, and require you to visit a branch in person to reactivate it.
I guess that means they're wide open to denial of service attacks, but that's another story.
I don't buy that as an explanation for ridiculous password limitations.
It is true that mainframe timesharing systems often had password requirements that are considered weak by today's standards. However, there is no reason for bank customers to even have accounts on the mainframe. Bank customer accounts have nothing to do with mainframe user accounts.
There is no good reason for any mainframe password restrictions to leak into the public facing web front end. To the mainframe, the web password should just be a data field in a database [1], and mainframe databases can easily handle data fields of sufficient length to support modern password best practices.
[1] Or rather, the output of hashing (with something like bcrypt or better) is just a data field in a database.
Almost all big companies handle security on this kind of cargo-cult basis, because it's easier than finding someone who understands security and letting them overrule stupid ideas.
PCI compliance requires we change our login passwords every two months. This to me seems to just encourage users to create insecure passwords and sticky notes with them written down somewhere in/on their desk.
Put yourself in their shoes though. The people at the top don't really understand security, other than the vague "only the right people should have access to stuff" requirement.
I think the problem is that the people in charge of making decisions are gun-shy. Because of their inability to properly evaluate the security itself, it's also very difficult for them to properly evaluate people telling them what the security system should look like, and they've been burned by bad decisions in the past, so they take the "lalalala do nothing" approach and hope for the best. From their point of view, it's a perfectly reasonable approach to the problem.
maybe this loud PR thing will go up to the people in charge and stuff could be actually resolved at the root?
Or maybe it will just be forbidden to tweet about internal policies in the future for security reasons, NSA cover style.
So, this is just someone on the BritishGas twitter account. We do not know if that person is repeating accurately what they've been told or just making stuff up.
Assuming they asked the correct people in BG website accounts security, and those people said "it's to prevent brute force attacks" we do not know if that's the real reason they do it or if it's just what they say to people who ask.
What is really frustrating is that there is no possibility of getting this changed - allow people to paste their passwords and use rate limiting to catch brute forcing.
Having said that, some aspects of BG's computer system are horrific for customers so I don't doubt that they do stupid things for stupid reasons.
Thank you! I get amazed every time the internet freaks out because XYZ Company confirms "blah", when in reality, it's just a single service rep, who probably just wants to get you off of the phone.
Its way worse with the advent of social media consultants/reps because their stupid explanation gets saved for the entire world to see, even if its about a section of a multi-billion dollar company they have no idea about. Low level reps have never had such an impact on companies as they do on social media.
As if blocking pasting actually stops brute force attachs... Can still just write a script that repeatedly makes those HTTP(S) requests. They accomplished nothing except annoy their more technically advanced users.
Do they think a brute force attack is done by someone copy-pasting in passwords?
Then they should clear the clipboard via JavaScript when submitting the login form, not prevent pasting of the password. Password managers are simply too much of a win to block.
Clearing the clipboard would be annoying for people who commonly copy a bunch of text out of a document, log in to their bank, and then paste the text somewhere else, but I suspect this is a rare workflow for most people.
I did work for a very security-minded HR outsourcing company on an html site to be used on a public kiosk and we also disabled paste via javascript for the same reason - to prevent a user from being able to paste in a previous user's password at the same terminal.
Unless I'm missing something here, lacking parametrization is not the issue here. The issue is that it's obvious they are saving the password in plaintext instead of hashing it, otherwise the password would never get close to an SQL query to allow injection.
But since you can't guarantee that every programmer and contractor, including future ones, write proper SQL, it's nice to reduce the attack surface a bit.
Reduce the attack surface by running the password through a proper modern Key Derivation Function (KDF) such as Scrypt before passing it to the database, not by running it through a few regexes.
Nothing in their policy about what isn't allowed[0] and they updated their system one weekend and my password quit working because it had % in it. I called tech support over it and they offered no additional guidance.
Citi Student Loan website maxes out at 6 or 7 characters and is utter garbage on top of that. Worst case though, someone could pay my student loans for me I guess.
It always concerns me when big companies like this do weird things when it comes to passwords. Why do banks for instance have stupid password requirements; max lengths, disallowing certain characters, etc.
Surely if they are hashing the passwords in any form then it doesn't matter how long the password is or what characters it contains.
I understand perhaps the view is some people are not good at remembering passwords and so would forget a complicated password - but they are unlikely to use a long password or special characters if that's the case.
The last bank backend I worked around was composed of several interacting systems, written 30 or 40 years ago in COBOL, which ran batch jobs overnight and communicated with each other by writing files to disk. We were strongly encouraged to get the format of the file exactly right, or the batch job in question wouldn't run and nobody would be able to sort it out until morning. Passwords weren't involved but, if they had been, I am quite sure they would have been stored verbatim.
So, two problems: multiple interacting systems, which means you can't just fix one, you have to fix all of them; and lots of legacy code. Versus: there would certainly be quite a lot of pain to implement a new system, and the old one appears to be working.
So it's a problem where the system must be kept up running no matter what and refactoring everything might cost more than having some security threats? Or is it just plain greed and "while it's working now, why fix it?" kind of thing.
> ... stupid password requirements; max lengths ...
> ... if they are hashing the passwords in any form then it doesn't matter how long the password is ...
Max lengths aren't inherently stupid. Presumably no one thinks 250MB password submissions should be handled, so you will be picking some number (possibly imposed on you by your stack).
A 250MB requests should get blocked by your web server way before it touches your code or your database.
But yes, you're right, limiting passwords can help avoiding edge cases where a long password is not handled correctly ecc... Just pick a sane length that no-one will hit, like 1000 chars or more.
English has at least ~0.6 bits of entropy per character, probably (much) more, depending. (Got that from Wikipedia, so don't know how accurate that is)
So even if you are using an English passphrase, the logical upper bound for a max password length is ~1.7x the length of the hash you use.
If you're hashing it who cares if someone wants to submit a 250MB password? They'll only be slowing their own session down - what I store in the database is always 256 bits either way.
Predictably this just regresses to what constitutes a big number. Take your pick for one that would cause noteworthy resource consumption in a given system.
I think you failed to understand the second point you quoted.
A 250MB password should be perfectly valid (if a bit foolish on the customer's part). That 250MB password will be run through scrypt by javascript running on the browser. (That may take a while, and a large amount of memory, but this is part of the CUSTOMER'S stack, not the server's.) Some amount, perhaps 512 bits worth, is then passed to the server. (Where it is run through another hash and then stored.)
It's not at all common or best practices to run an expensive key derivation function browser side. Doing so adds little to no additional security -- if you don't trust the TLS channel then you are screwed any way you look at it.
It's not common, but running an expensive KDF client-side still greatly slows down a bruit force attack if the password hashes are stolen, without increasing load on your server. The fast one-way function run server-side then prevents the client from being able to submit a stolen hash, forcing an attacker with a list of stolen hashes to perform the full expensive bruit-force attack.
In the 1980s I don't think hashing passwords was common, it would have taken too much processing power, and the database fields on the mainframe don't support weird characters or a length of more than 8 characters.
I wish this wasn't the case, but these systems are so old behind the scenes, that lots of it simply can't be changed without massive re-engineering. I have friends that work for a company who transfer COBOL applications from mainframes to JVM COBOL running on standard servers, it's a massive task, and takes years and lots of money.
I would love this to be true, since it would basically double my net worth, but it's very rare for a security incident to kill a company. Target is the exception, and just required two human sacrifices.
It was standard to hash passwords in /etc/passwd back in the 1980s.
Still, when you pin code is limited to 1 million combinations, all the hashing in the world isn't going to save you. You need to keep your DB secure, no matter what, and that's where resources were applied.
Some of this kind of system won't actually hash the password but encrypt it and use an HSM to secure the keys.
Wherever you see a password prompt where the ask for specific characters of the password, they're either doing this or shudder storing it in the clear.
If a bank use passwords at all, its a big red sign that they only care about the appearance of security. A password do not strongly identify a person, and should not be used for anything that involve high value and easy stolen property.
Most banks I know uses pin and either a hardware token or a bound smart phone. Its far from perfect, but at least someone has to steal a physical object or hack the phone system to start their brute-force attacks.
"Most banks you know"? I'm genuinely curious, I don't know of any bank like that in Canada, and I'm in the US weekly and I've never heard or seen it there. I've seen token generator keychains, but what do you mean about the phone?
Both my personal use credit union, and the bank my volunteer gig uses, have an outsourced authenticator who logs the ip addresses I use, and if I'm attempting to log in from a new address they SMS or voice call a number on file with a six digit number I type in to authenticate the new device. Neither the CU or bank have anything to do with each other, but use the same system, so I'm guessing its some kind of nationwide outsourced system that "many" financial institutions use.
Still have to enter your password to verify its me on my computer today, and not my kid screwing around on my computer, they only SMS authenticate perhaps once a month.
The same outsourcer apparently does password recovery when you get locked out. The bank requires full password recovery process if you don't log in for 45 days, which is an unholy annoyance for a sleepy volunteer org. The life of a treasurer is never easy I guess.
Its moderately annoying as my phone lives on its charger in the bedroom if I'm at home, and the desktop in the office is at least 75 foot walk away, so when the authentication service feels like pulling my chain, I swear a lot and make a trek and inevitably the login times out so I have to start all over again once I fetch the phone. Which fits in with stereotypical security theater, you "win" if you make it inconvenient, no need to actually make it secure.
(edited to add I live in the USA, upper midwest, vaguely near Chicago, everyone else responding is at least 4000 miles away, I interpreted your request as how they use phones to auth in the USA, so, well, this is how they do it)
In Brazil, most banks use two-factor authentication in some form for internet transactions.
One of my banks gives me the option to receive the code through SMS, generate it through a phone app or with a dedicated keyring token. This is a option I can make at the time transaction-time.
The other requires me to authenticate each new machine I login from, through an SMS. A bit less secure.
Biometrical authentication is also a thing. The biggest banks already have some form of it (fingerprint or hand palm), and I can even make transactions w/o a card, using only fingerprint and password. Actually, I only carry credit cards nowadays, the bank account card stays at home and use fingerprint to withdraw.
I've been online banking in Norway and Sweden since 1999 and I've never seen a bank that just uses passwords.
For phones you download an app and enter a unique security code that you get from your bank. This, combined with some uid on your phone, creates a unique salt and basically ties that copy of the app on that phone to your bank account, so only your phone can log into your account. Your phone now becomes the "something you have" in addition to the "something you know" (your chosen bank password)
Every Swiss bank I have accounts with (Credit Suisse, Postfinance, Raiffeisen) have internet banking protected with two factor authentication. The second factor can either be a chip card with a reader (protected by a PIN, and you then enter a code shown on screen and it returns another number), an SMS token or an iPhone app which reads a picture of the screen (!) and returns another token number (with a SMS token fallback).
None of my personal accounts in the UK use two factor authentication. Same goes for the majority of friends and family.
Only one (former) account ever done this, and it was own used when adding a new payee records. It used EMV CAP (http://en.wikipedia.org/wiki/Chip_Authentication_Program) with a separate smartcard (not my EMV compliant debit card).
All of my business accounts offer two factor authentication, recently shifting from SecurID-style TOTP tokens to EMV CAP authenticators.
Barclays bank uses two-factor authentication for logging into their online banking (using your card, so that you have to enter you PIN for your card on the little authentication machine to get a code to log in), although you can also set up a PIN to log in without it (I haven't bothered - it's safer not to, right?!). You also need your membership number and a memorable word AND a number as far as I can remember (I do it automatically now)
They also require this authentication step to be carried out for sending money to someone else online for the first time. They also require you to enter your PIN against your card using the same mechanism when you go into a branch, as they cannot access details about your account without you doing it. I suspect it stopped people mugging others and they walking as saying "Can I withdraw £100 on this account here please?" with the card they'd just pinched.
The Barclays one is called PINSentry and they've had it for nearly 10 years I think? My device still hasn't ran out of battery (it gets switched on when you insert your card).
My wife is with Natwest I think and she needs the little card device for setting up new payments but logging in does not need it.
I don’t have a mobile phone; my experience with NAB’s Internet banking is that there are a few things which want that, such as viewing or changing daily limits, but so long as you never set up SMS Alerts just about everything else is fine. I don’t believe I’ve ever run into any problems with them due to not having a mobile phone. If you’ve already set up SMS Alerts, I don’t know what the situation is.
Wire transfers tend to have a $35-$50 fee and require you to schlep down to the bank during business hours and fill out annoying paperwork. So, yeah, we don't use them except in emergencies.
Do we have a misunderstanding of the meaning of "wire transfer" here? Surely you can just send money to someone else's account through the bank's internet banking website?
How else do you pay for stuff like rent, and, well, anything, really?
Rent is usually paid by check, though poorer people who may not have bank accounts of any kind often use cash, too. Large-scale landlords (corporations renting many units) sometimes take credit cards or be able to setup automatic debit from a bank account. Obviously this sacrifices a good deal of control and if they screw up (intentionally or otherwise) you get to deal with all sorts of shit.
"Electronic bill payment" in the US often means your bank mails the receiver a check. Some subset of businesses are setup to turn that into a direct transfer. In no case has it ever been worth the hassle. I try very hard to avoid anything that can't be paid for with a credit card, since that is, by far, the lowest-friction payment method in the US.
Everything else, cash, check, credit/debit card, or sometimes direct debit. Only active businesses are going to be set up to take cards or do direct debits. If you want to give money to an individual, you give them cash or a check.
Okay, this explains quite a lot about the state of US banking, and why credit cards are so popular there. In Netherland, almost nobody uses credit cards, because they're less safe and more expensive than our other options. The only reason I've got a credit card at all, is to make international online payments. Even for domestic online payments, we've got a much better system. But internationally, there's nothing. Just credit cards.
I do get the impression that the US should be a great market to start a more modern bank and compete all the crappy old banks away. I'm sure all internationally operating banks have tried this. So why are they not successful?
The US is huge and diverse. Many of our states are larger than many European countries. California's population is about the same as Poland's, New York's is a bit bigger than the Netherlands/about the same as Romania.
But for more than two centuries, the US has, by Constitutional mandate, had one integrated market. Changing banking in the US means changing more than 300 million people, millions of businesses, and thousands of financial institutions with enormous inertia.
There is no way to do that quickly without Congressional intervention. Which brings us to gerrymandered congressional districts and half the country cleaning guns and stockpiling ammunition every time a new law is proposed that isn't to force the religious right's (im)morality on the country, especially when the law might cost anyone other than their political opponents money in the short term, no matter what the long-term benefits are.
There's a reason every minuscule step the US makes toward real health care reform is a big deal, decades after the rest of the western world had already figured it out.
It's mainly a result of the morass of outdated banking regulations in the US.... any "new" bank would have to follow the same rules and would end up with the same problems.
In Canada you can email people money up to $2000 but it costs $1.50 per transfer so I tend not to use it. You can also pay most bills from large institutions online (utilities, credit cards, tuition, taxes, etc).
I've paid rent using cash, checks, and pre-authorized debit (you give them your bank account number and sign a contract and they withdraw from your account every month). For vehicles or property it's usually a certified check. Anything else goes on my credit cards.
I believe you're a UK but no offense intended if you're not. As an actual american I only write about three or four checks per year, everything else is online.
We do pull and push.
Pulls are an unholy PITA to set up where you give them all kinds of personally identifiable information which they hopefully won't lose, then they make multiple couple cent deposits to your account, then you tell them what the amounts were and they tell the bank, which creates a certain relationship which in the Future is very historical trust based. So click here on your car insurance site to make your biannual car insurance payment exactly like the last 20 payments (well, slightly different amounts, but ...) Ditto the mortgage website, the electric bill, a couple others. Basically very long term relationships, I'm unlikely to just randomly stop paying the monopoly electricity provider. This is a direct acct to acct transfer.
Pushes are easy to set up but more of a pain to use on a monthly basis. No one has control over pushes other than yourself. You send money to a postal address, and who knows what they do on the back end, individual old fashioned checks or batch up or wire transfers who knows. This is more for credit cards or temporary less formal associations. You go to your bank website, tell them the postal address (they'll save it for later use) tell them how much, click send, off it goes.
Speaking generically, most USA people use credit cards or paypal or the zillions of small time competitors when someone wants money from them, and they interface with the bank for you. So Paypal can eat money directly out of my checking acct to send cash, up to certain limits. This is vaguely ATM like, sort of a web interface to a ATM. Or it just gets added to the CC balance. So it would be really weird for me to pay directly for gasoline or even food, I generally CC that, and then send one very large "push" bill payment from the bank to the CC per month.
So Americans mostly do electronic pushes, pulls, and aggregators online, although we do have checks for non-electronic people.
I write a check to the school district for book + other fees, like $50 per year per kid. Technically its illegal to demand payment for free public schools but the PTO spends it on "free" after school activities so its kinda a donation and I think we get our monies worth. Also my wife buys an organic grown fraction of a cow from a local farmer every year or so, and the butcher shop takes electronic for processing but the old school farmer still does paper checks. Some tradesmen (plumber, carpenter) only take old fashioned paper checks, although that is very rapidly changing as they all get smart phones. I switched to a CU probably 7 to 10 years ago and since then I've written a couple dozen checks total, I'd have to find it to verify because I keep it locked up.
Some really old people, like non-computational, obviously write a lot of checks. I have an elderly uncle who had to pay an extra bank fee for writing more than two dozen a month, which seems weird to me.
Poor people with serious legal / financial issues are unbanked and mostly go pure cash. There's a whole industry grown around ripping off those people when they try to interface semi-legally with the financial system. This is probably less than 1/4 the population. Like if you owe child support or a court judgment, all your electronic money will simply disappear, but not your cash, leading to some peculiar behaviors.
Wow, this sounds insane. Here in the UK they have recently improved the electronic transfer system so that money appears in the other account (clears) in 2 hours or less (practically instantly for accounts at the same Bank). I do not know whether large bank transfers using BACS or CHAPS incur a fee but most people happily send money to other people electronically as few people have cheques anymore. The banks seem to have stopped issuing cheque books, and no shop that I know of will accept them, so it effectively killed cheques. The older generation probably struggle without them.
They have recently pushed out the mobile payment system called PAYM (someone obviously got paid a fortune to think of pay + mobile, eg. pay + m ... . . paym) where you can send money to anyone else with their mobile number. They need to have registered their mobile number with their bank for this to work (and not all banks have signed up to the system) but it should make sending money really easy.
People seem to use Paypal a lot for sending money around but they're greedy with fees so I am keen for this PAYM system.
A pin is just a very short password. A bank using only a password would of course be ridiculously negligent. All banks I'm familiar with use 2 levels of authorization: 1 to log in, 1 to authorize payment.
I have 2 bank accounts. One with ING (a major Dutch/international bank), which uses a password (without special characters unfortunately) to log in, and an authorization code to authorize payment. In my case, that authorization code comes from a piece of paper with a bunch of one-time codes on it. This is an old system that dates back to when you called them directly by modem, rather than over internet. Nowadays I could also have the code sent to my phone. But phones can also be stolen, so I don't see the point.
My other account (at Triodos, a much smaller Dutch bank) uses a pin + hardware token at both stages. I wouldn't also having a ridiculously long password there.
All of the bank accounts I have in Canada let me send $2000 with nothing but a password. They also won't let me use non-alphanumeric passwords and don't support any two-factor authentication. Same in the US.
Of course, if anyone did try to steal my money this way, the bank would reverse the transfer and give it back to me.
Sounds very insecure for a bank. Will they really automatically reverse any transfer you object to? What if they don't control the target account? What if there's no money on the other account anymore? What if it was a legitimate payment, you got what you ordered, and then you had the payment reversed?
I see a big hornet's nest of potential problems in a system like that.
I guess they try to pull it back and if it's not possible they eat the cost. I imagine any bank that tried to force people to use 2FA and/or get rid of the zero-liability policy would lose a lot of customers.
Not in the US. Not one of my banks or other finance-related websites uses two-factor authentication by default. I haven't looked to see if any offer it as an option, but I tend to doubt it (it certainly isn't advertised).
The US's personal banking industry is like 20 years behind the rest of the developed world. Not sure why, probably because the banks have all the money to lobby to keep things the same.
The US's personal banking industry is like 20 years behind the rest of the developed world
People say Canada is a half-generation behind the US in banking innovation, which is generally in Canada's best interest. They've never had a banking crisis.
Not sure why, probably because the banks have all the money to lobby to keep things the same.
This response is worse than wrong, it's assuming bad intentions.
For personal accounts, banks are responsible for your money, even if the hackerz keylog your password and log on as you and steal your money. US banks already have all the incentive in the world to drive down fraud on personal accounts, and yet they seem to have decided it's not worth the time and money to clamp down on it.
Most likely it's because there are always other ways of fighting fraud. The US banking system is full of reversible transactions. From the outside, it sure seems the best use of limited resources is to choke the irreversible endpoints.
> The US's personal banking industry is like 20 years behind the rest of the developed world
>> People say Canada is a half-generation behind the US in banking innovation, which is generally in Canada's best interest. They've never had a banking crisis.
The financial crises in the US have all been caused by investment banking, innovations in retail banking are unlikely to ever cause a financial crisis.
Before laughing at how stupid this is, remember that your debit card is secured by a password that consists of exactly four decimal digits. I really wonder when this is finally going to change, but I hear some futuristic banks allow up to six digits already.
Well, it's not like my card is hooked up to the internet for everybody to try and log in.
PIN isn't particularly vulnerable to brute force anyway, as number of failed authorisation attempts is strictly limited to something like 3, and a fraudster has to risk capture by being physically present at each attempt or 'trying out' a stolen card, and having their face recorded on cameras.
I haven't seen any advantages for using 6-digit or larger "passwords" for that particular scenario. The largest practical security benefit seems to come from enforcing random PINs and not allowing to choose - since the banks that allow to choose are vulnerable to "dictionary attacks" of trying the user's birthday (obvious from other stuff in a stolen wallet) and stuff like 1234.
Now, checking "signature" instead of chip&pin, now that's an example of blind trust.
> Now, checking "signature" instead of chip&pin, now that's an example of blind trust.
If even. I cannot find the original report, but there was a guy who tried all kinds of weird signatures including "I STOLE THIS CARD" and it only took purchasing 3 most expensive TVs and signing "NOT AUTHORIZED" for someone to question him.
Interestingly, the signature could be argued to be better in some cases:
Under British law, a forged signature is never your fault, and the bank/merchant/card processor are liable (I can't remember exactly which, I think it depends). One of the reason that card issuers were so keen to switch to Chip&PIN/EMV is that the liability was turned over to the user. As they thought EMV was "unhackable", always a dangerous thought, it was always assumed that the user had told someone their PIN. It wasn't until relatively recently that the Cambridge University security research group showed that it was crackable, and the banks/etc started taking liability in some cases again.
>> One of the reason that card issuers were so keen to switch to Chip&PIN/EMV is that the liability was turned over to the user.
Not really true.
The main reason was the switch in liability to the merchant, if the merchant accepted a transaction without using EMV and PIN.
AFAICT the Cambridge research isn't really that relevant, it doesn't really give you practical attacks, and it's not so much a crack on the chip security itself as it is a piece of Man-In-The-Middle hardware (IIRC, haven't read it for a couple of years).
Under UK law, with a credit card (debit is different), the liability is never with the user. The bank may claim that it was obviously you that did it, or that you gave away your PIN, but where credit is concerned they legally have to refund you the money pending an investigation.
Debit is less strongly protected and comes under banking rules and guidelines, and if you report unauthorised activity as fraud they will usually still take your side.
--edit-- I'm not trying to say EMV is bulletproof, nothing is bulletproof, but the primary method anyone's going to use to get your PIN is still social engineering, or possibly some sort of compromised terminal hardware, which they'd have to make from scratch because accredited devices disable themselves if they detect they've been tampered with.
I have no doubt you're right, and the banks absolutely should not reject fraud reports based on PIN.
I've had a read of the first paper there, the nopin one, and it reads like a really preventable flaw in the IAD, which (as it's issuer specific) could be very easily fixed without the involvement of terminal vendors. I agree with the conclusion that the TVR is a flawed concept though, I had always assumed (never having worked directly for an issuer) that there would be enough data in the IAD to marry up the terminal and card perspectives on what had happened.
And on the second one I'd be the first to agree that SDA and offline-plaintext PIN are a bad idea, I could have told you that when I did my first implementation in 2001!
--edit-- I had actually assumed that by now the cost differential between SDA/plaintext and DDA(or CDA)/encrypted cards would be so small that nobody would use the SDA cards any more. Guess I was wrong!
Actually that's subjective. If the overall fraud is lower then (potentially, I'm sure this doesn't actually happen) fees, charges, interest rates etc could be lower for all users, therefore they would benefit from security that lowered the overall cost of fraud and the overall number of incidences of fraud, even if individuals that directly experience fraud are worse off.
Yes, but "security" isn't "overall cost", its about risk. I am more secure, even if my expected cost is higher, if I don't directly bear any risk of unconsented loss even if the overall incidence of fraud is higher and I am paying a distributed share of those costs.
I was once refused a consumer credit application for a kitchen appliance because I'd forgotten to sign the back of my credit card. I had a passport and a photo driving license on me at the time but because there wasn't a signature they "couldn't be sure" it was me so they refused to process the application.
I signed it in front of them (which matched my passport signature BTW) but was politely declined as they'd seen the card unsigned.
Another example of security policy getting in the way of actual security.
I had a slightly similar experience: I forgot to sign the back of my card, but the person just asked me to sign it and then made sure it matched my signature on the receipt.
You could have stolen the card of an homonym, so it kind of make sense. Printing a photo of the owner on credit cards would go a very long way and isn't too expensive, but this is a very high inertia industry.
Cards are way different. They combine something you have (the card) with something you know (the PIN). After three false attempts to enter the PIN you have to unlock the card going a different route. In such a scenario, 4 digits are fine.
You can't lock accounts only protected by a password and accessible by anyone (via internet) this way as this would invite for Denial-of-Service attacks (locking your account with three failed attempts).
I have had quite a few sites block my account for three bad password attempts and I had to actually call the company to unlock the account (this was always a financial services company).
It's quite annoying as none of the sites warned me about the impending account block after the first or second try. I guess it's an inconvenience that is worth it for the extra anti-brute-force security. Being locked out due to someone personally locking you out as you mentioned might also be annoying, but I honestly rather be locked out of my account and therefore alerted that someone is trying to gain access to my data than not.
Why these same sites limit my password to a specific number of characters and disallow special characters is beyond me though.
It's always annoyed me how people set the lockout after n attempts value to ~3 or 4. Why not 100? It makes almost no difference in your chances at brute forcing a password, but means that the real user trying all the passwords they might have used won't get locked out mid way.
If you type a wrong password in "su" on OpenBSD, the binary responds immediately telling me I'm wrong. On Linux, it does this stupid artificial 3 second penalty.
The Linux way sounds better, but the OpenBSD way is better. If you want people to use passwords, don't do petty nagging of them when they make a mistake.
On Linux when I mistype a password, I control-Z the "su" session and launch a new one instead of sitting around like a scolded schoolboy waiting for the binary to give me another chance.
> It makes almost no difference in your chances at brute forcing a password
Depends on how many people use a password in the top 100 most common vs. how many use one in the top 3. I would think it would be a sizeable difference.
> I have had quite a few sites block my account for three bad password attempts and I had to actually call the company to unlock the account (this was always a financial services company).
GoDaddy does this. It's the main reason I left them (before all the more recent shenanigans)
It's secured by a four digit password and self destruction after three consecutive invalid PIN entries. Which is plenty secure against brute force. Or is that just the way it works around here?
I actually rely on this self destruction, I have a scrap of paper in my wallet with "Pin Numbers" written on it along with 3 random four digit numbers, gives me minor peace of mind that if my wallet is lost and found by someone that wants to try and use them, hopefully they'll lose them to an atm rather than using them online.
Unfortunately it doesn't prevent them using them online as well. At least for my cards, if I lock out the PIN I can still use them for non-PIN purchases.
A tiny number of digits combined with the standard, visible input system is a recipe for 'shoulder surfing' attacks. I'm not proposing a superior system, just pointing out that brute-force attacks are not the only thing to beware.
it's not a password, and it doesn't give the same insurance.
There were some proposal of at home card readers in the 2000, but it never got very far, it was not really practical to secure either.
I think the current trend of scratch credit card could be onto something for online buying, it's a temporary credit card number valid just for a few hours, and then it's deleted from the bank system.
Mine is 10 digits. I thought the 4 digit limit was just a societal assumption? (I'm being serious, I thought it was (near) universally allowed to be longer, people just didn't bother.)
Not common, and using anything other than 4 digits is not wise if you want universal support especially when travelling - 6 digit cards are not 100% compatible with every ATM/card machine because some (most?) only allow 4 code entry. I've never heard of 10 digits and the compatibility must be even more limited. Where do you live and what happens if you try to use your card at ATM's abroad?
It's not the case, it depends on the issuing institution.
Also, there is a practical requirement to have it short; as physical merchants value quick processing, and having to type&re-type long passwords delays other people behind you - so they want long PINs to be unpopular.
You don't have to re-use passwords. In fact, don't re-use passwords. Keeping them in a password manager helps a lot with this. I have over 50 unique passwords which are all long, generated random strings. But there are a few websites, including British Gas, which get shitty weak passwords because they pull dumb crap like this in the name of "security".
The standards allow for up to 12. Not that people always implement them properly, but that's what you're supposed to support if (like me at the moment) you make credit-card terminals.
To me this sounds like a crazy PCI Compliance related rule; and someone who doesn't understand anything about the PCI Compliance process or brute force hacking made the tweet.
When I ran a web-site with an e-commerce store that accepted credit cards; I was required to have PCI Compliance scans done.
One of the things they had me do was turn off the autocomplete on the password field with autocomplete="off". I have no idea how that makes things more secure.
A lot of the things they made me do in order to be PCI compliant made no sense to me. I think I spent a week trying to convince them that my "error" page which showed up when someone mistyped a URL was not a security risk and was not something I should remove.
autocomplete=off does not prevent you from using keepass, it prevents your browser from storing your password in your HD in plaintext.
It's arguable that it's not the website's decision where the user caches it's passwords, but in high security environments I don't think it is an overkill.
I doubt the autocomplete browser feature applies to password entry. It would freak people out if their browser started suggesting the password as you typed.
It does apply for the username/email field, though.
For a password field, "autocomplete" doesn't mean to suggest candidate completions, but rather to prefill with the password part of a previously saved username-password pair, and to offer to save such a pair (or update an existing one with a newly entered and different password) when the form is submitted. Giving the field an "autocomplete" attribute with the value "off" disables this behavior, which matters for PCI compliance because it forestalls browsers from storing the password when they might do so insecurely.
One could argue that a cross site scripting attack could use someone else's browser to paste to the site. So disabling paste disables one (small) vector for an attacker to use someone else's computer to attack.
Deleted my comment but I just realized why we did this -
The product I was working on was to be used on a shared public browser / kiosk. The reason was to prevent one user from pasting in the previous user's password.
I would guess that the single greatest hole in computer / network security comes from the terror regime of incompetently enforced “security”. Users WILL get their revenge by undermining such measures any way they can in order to re-establish some usability. Like the best camera is always the one you have with you, the best security is the one your users will actually support, and not feel forced to circumvent.
Call me a conspiracy nut but after reading all the accounts of banks and companies ridiculously reducing keyspace in weird ways (give me a good legacy-tech reason for [0]...) I'm starting to believe that they're doing it on purpose.
My bank has a password-subset request form for logging in. This of course means that passwords are not being hashed. Also, I can be positive that the keystrokes used for the subset, are recorded and are visible to staff ("you have the correct letters, just try turning off CapsLock" was one response I got).
If only there were malevolent hackers that could create I don't know automated post (please let it be post!!!) requests . That would be brute forcing nightmare.
