Hacker News Reader

Comment by patio11 | Hacker News Reader

There is a (mildly) compelling reason for every bank to have a stupid password rule which is mutually incompatible with every site in existence: it means that compromising that other site's identity:password dictionary and then running it against your bank results in zero successes. Regular users reuse passwords given the opportunity to do so, and most of them will happily cough up their bank password to, quite literally, any site on the Internet.

There's got to be some weird game-theory solution for "Maximize for security while simultaneously minimizing the sum of all accounts on the Internet which have a password that could possibly collide with a valid password on this site."

View on HN

As someone that has been the lead for many large banking systems, I can say your intuition on this one is off. Banks enforce these rules because some internal security group set the rule a while back and thats what they use. Many smaller banks use whatever password scheme the banking software service provider has as its default. Its just bureaucratic deluge. Its certainly reasonable to pontificate that this deluge results in safety per your rational. But I have never seen a study that shows this to be so. It may well be that many set their banking password as the first account they ever used on the Internet and then reuse this same password for subsequent systems.

I think using the password alone in the bank is a stupid idea in the first place. If all that stands between my dollars and miscreants is a few characters - this is careless to say the least. Think trojans/keyloggers.

My bank gives me a small card reader (not connected to PC), where I insert my debit card and need to put in my card pin. This gives a one-time code which I enter together with my password to login.

However, this is not all - in order to do anything meaningful (aka transfer money), I need a confirmation code, which is done by me typing into the little machine the amount, part of the account number being credited, and of course my banking pin to begin with. So, I effectively sign the transaction, and having the reader totally offline makes me somewhat confident in its security even if my linux laptop were compromised.

Of course all of this needs to be matched by the proper security rules on the backend, which, given their cluefulness with frontend, I trust them to have.

p.s. That said, indeed now I remember that the password rule they had is kinda stupid. But I have only one bank and I can make the exception for them, given that they have done their homework otherwise.

p.p.s. and no, I would not like to have my bank operations protected by the unlocked private key - the added convenience in this case is not worth the risk at all.

Ours just sends an SMS with a one time code for each operation.

This is much better than password alone - and very nice usability-wise. But it significantly increases the area that you need to trust to be safe. I would not like to have it for all of my accounts. But would be cool if my bank used this system for transactions under 100 euro, for example.

Quite a few websites I use offer this (usually in addition to a password.)

I won't use it, because it means I will be locked out if my phone or SIM breaks.

This could easily be fixed by having a backup phone number to use if the first one fails, but for some reason they never do that.

And probably you are right. I can't use my internet banking of one Singapore bank right now. I am not there and cant receive an sms with one time password on my Singapore sim. It sucks!

Set up a Google Voice number and have the text sent there. GV can then forward that to your phone, so you have the convenience of getting it on your phone with the knowledge that you can get to it even if your phone is not working.

My bank has an offering that lets you select between getting the code as a text or as an email.

Only if you're in the US, unfortunately.

Bank of America SMS doesn't work with GV numbers. I know .. I've tried it multiple times :(

At least with the Google system you can set-up one time codes that you can keep in a safe place.

Few years ago my friend had an account in a bank that gave him security token, that generated a random number every 60 seconds, that had to be appended to password during login. So even if someone sniffed your password, it would be valid only for less than a minute :).

I think it's a great solution and I don't understand why it's not widely used.

less than a minute is more than enough to transfer your money to a place where you will never see it again. ;-)

Less than a minute is also short enough that the bank can simply deny a second login attempt during that time without causing any inconvenience to you.

Absolutely. i got your TCP segment with data on your WIFi, and sent a TCP RST from a location with the lower overall latency - so both your SSL connection got reset.

While you hit "reload", I establish the connection and login.

Your attempt is the second login attempt. As you propose, it's denied.

Your next steps, while I am changing your contact email and other info ?

Short answer from my experience is cost. The individual tokens have a cost, then there's the management overheads of running the system. Initially it doesn't seem like too much but if you've got a customer base numbering in the millions, it can get quite pricey.

Obviously if the cost (to the bank) of online fraud gets high enough it starts to make more sense. What's interesting is that some online apps (eg, World of Warcraft) have seen the benefits of providing 2-factor authentication faster than a lot of Financial Services companies.

2-factor auth of one kind or another seems to me to be a good idea for online banking, given the prevalence of banking trojans which have keylogging functionality.

With smartphones becoming increasingly prevalent, there's no reason a software OPT on your phone couldn't be used by many people.

Those without smartphones could fall back to fobs or more "traditional" forms of auth.

Question: what is a good/trusted one-time key generator for Android and/or iPhone?

Google offers one. http://code.google.com/p/google-authenticator/

It implements an open standard for OTP and they provide source for a PAM module to require the OTP on the computer side.

This is a horrible solution. I don't care what security experts say about two-factor authentication. I'm not about to start stuffing my pockets with a pile of security tokens. I have more than enough keys on my keychain, thank you. Unless everyone can agree to use the same physical token, I simply refuse to use a service that makes me carry an extra piece of junk with me all the time.

Most of them have an SMS option now. Bank of America offers the token or just one-time-use SMS'd security tokens.

> Most of them have an SMS option now.

Being forced to pay a small fee (by your phone-service provider) to log in isn't much better, I think.

People really pay to receive SMS (assuming you are on your home country)?

Yep. (I don't recall whether Verizon charges me 10 or 20 cents per text, but it's one of the two.)

It depends on your contract. In general, by default, you pay a bit for every text (10 cents maybe?). But you have the option of paying a flat rate for unlimited texting, which is generally something like $10/month. Most people I know choose that option.

Let me ask again the parents question for clarification. Do people really pay for the received sms-es? It sounds like total bullshit, because you don't have an option not to receive sms from a person, like you have with calls.

Absolutely (in the US here). Some carriers will allow you to block all text messages, which can get rid of the annoying ones you wouldn't want to accept, but also forces legitimate ones to get eaten - causing some people to think you're ignoring them when you actually had no idea they even tried texting you in the first place.

Yes, in the US, if you have no TXT plans, you pay for receiving TXT messages.

From horrible providers, yes. The big three legacy operators in Canada charge 15 or 20 cents per unless you're specifically on a plan that includes a larger allowance.

It's easy to negotiate to get them for free when you have any amount of leverage on the provider, but out of the box you pay.

That's a problem with cell-phone providers who overcharge for SMS. An SMS is almost free nowadays, in some cases it actually is free since it goes over channels that would otherwise go unused. SMS seems like a good, cheap, ubiquitous solution for most of the developed world.

It's a particularly horrible solution when your bank decides to replace their existing clever nigh-impossible-to-sniff multi-factor authentication system with a little dongle sent to your home address whist you overseas. Specifically, I need it to pay off my credit card bill with the same bank; I can still log in and shift money between savings accounts at will.

Ah, but I can still pay my bill by telephone and all I need is to dial in the card number when prompted...

There's an RSA app that you can download for your phone.

Link?

RSA SecurID Software Token for iPhone and iPad (http://www.rsa.com/node.aspx?id=3651)

Search Android market for "RSA SecurID".

Lastpass and gmail use an app called Google Authenticator to provide two factor authentication. Works a treat, and I always have my phone.

Lastpass is awesome and even with google authenticator if you do not have your phone with you they give you the option of printing out like 30 one-off codes in case of situations where your phone is dead or missing.

Although slightly ahead of its time for the masses there are implementations which do not require you to carry another device. You can use your telephone and be provided with your second factor via voice, sms or application running on your smartphone.

For example: http://googleblog.blogspot.com/2011/02/advanced-sign-in-secu...

Google two-factor is an iOS/Android app. The tokens are good for 20 or 30 seconds. See also: OpenID.

The only problem with this, is that it requires everyone to trust a single third party with the authentication. Since the input space that you type in is small, any one-way encryption is easily reversible. This means for every site that the code is good for, you would need to reveal a means to generate the code, rendering it the password problem all over again.

Alternatively, the key-fob could have an arrow to select which site to show the key for, but that would be cumbersome. Personally, I think that a solution similar to the ssh one would be best in that you have some sort of pass phrase that you type into your browser, and it unlocks a private key that can prove your credentials on web sites.

That's bad solution. As well as password lists. Because it doesn't verify sum or target of the money transfer. Money can be transferred to anywhere when you give the confirmation code.

> and I don't understand why it's not widely used.

RSA, one provider of such tokens, was hacked making many of those devices worthless.

RSA was hacked because someone in Personnel opened an attachment supposedly from a recruitment agency.

(http://www.pcmag.com/article2/0,2817,2391951,00.asp)

Very frustrating that the expert people supplying the extra security for the people wanting extra security are the people falling for stupid stunts like "include an infected Excel file, and hope someone opens it".

That's not an inherent flaw in the idea, though, just in RSA's implementation. There's no real need for the servers to hold on to private device-specific data.

If the description of password+number is accurate, then it's a poor solution because it means your password is sent to the bank as opposed to being hashed and the hash being sent to the bank.

This is common practice. Our password forms all over the internet send the password just as part of a normal request. We rely on SSL to protect that data as it goes over the wire and then there are all sorts of ways that it might be stored in plain text somewhere on the servers.

They could just, in RAM, take off the last 6 characters of the password they got and treat those as the token with the rest being the password itself. At this point it's not much different from passing them separately.

The main point of the original rant was that we have a solution that doesn't require this, but it's not used for any websites.

This comes up every time passwords are discussed, and it's a bad idea. A password sent over a secure channel is fine. A hashed password sent over a secure channel is generally fine, though more complicated. A password sent over an unsecured channel is not fine. Neither is a hashed password sent over an unsecured channel.

Hashing the password before transmission gains you basically nothing. Hashing on the client side simply means that your hashed password becomes the effective password. Anyone who could theoretically sniff the password could also sniff the hashed password and perform the same kind of impersonation or man-in-the-middle attacks. You're introducing a bunch of complexity (and breaking compatibility with clients that don't, e.g., support Javascript), and you're getting nothing useful in return. And yes, you could implement some kind of challenge-response and basically try to reimplement a secure handshake and auth, but you'll probably get it wrong because security implementations by laypeople are generally quite broken, and at the end of the day, you should just turn on SSL and do it the way that works.

Because they are hellaciously expensive, in terms of:

* cost to retrofit the backend of these systems onto the bank's retail software

* cost to roll out tokens to customers

* ongoing support costs for e.g. lost or broken tokens

To all that, you have to layer on the fact that tokens are priced for a different market (enterprise security), so the existing products aren't packaged in a way that makes them palatable to (say) Bank of America's many tens of millions of customers. You can't wave a magic wand on that problem either; tokens are packaged the way they are now because that's how you can keep a token company in the black.

Because they are hellaciously expensive

You know, I have a checking account that I don't keep a lot of money in (because I rarely write checks nowadays) but have had so long that I don't really want to close it. I was surprised to notice last week that the bank is charging me $12/month in account fees unless I keep a minimum of $1000 in it at all times (effectively, an interest-free loan to the bank). For $144 a year, I think they can afford an RSA token or something better than the existing nonsense.

I know, the bank makes money from fees and that's the price I pay for access to a large ATM network..yet I distinctly remember a time when they made money from lending, while still managing to have a risk management policy grumble grumble

Banks are moving to multifactor auth systems. Expense is slowing the process down. Buy me a beer next time I'm in San Francisco and I'll give you anecdotal details I can't give here.

I think one obvious (but HN-unfriendly) point to be made here is that the overwhelming vast majority of bank customers could give a shit about online authentication systems.

Switch to a credit union, then. If your profile info is accurate, you live in a region served by the SF Fire Credit Union (http://www.sffirecu.org/). I switched to them a few years ago and it's been a great experience. Save yourself that $144 a year.

They have the largest ATM network on the planet; every ATM is free-of-charge. (That is, they'll refund the fees, if the ATM charges any.)

Make it an optional smartphone app, like Google's two-factor auth. Maybe let people buy a token like Mt.Gox does (they are hardly huge, and they could afford it...name.com and World of Warcraft too.)

You know what was expensive? The bank bailout. I want my $8,333 that I'm paying to keep banks open back.

I have no idea what you think bank bailouts have to do with online account security.

The question was asked, why don't more banks use tokens? I provided an answer. That's all.

It is widely used. At least in several parts of Europe I've been to and/or lived.

With some variations such security measures are ubiquitous here. SMS tokens, an electronic device that generates numbers. A card full of numbers of which a couple of them are asked before each transaction, etc.

My bank requires both my pin (numeric) and password to log into my account, and SMS's me when I login. If I need to transfer money to anybody outside of my usual payment recipients it SMS's me a token that I have to enter.

That's not failsafe but it raises the bar quite a bit above 'enter password to own everything'. Also, no extra hardware required.

I have two accounts with security tokens. In one case they charged me $20 for the token, in the other case they gave it to me for free with the account.

It's mildly annoying in that you need to take the token with you if you want to have banking at your fingertips, but then it does mean you're extremely unlikely to be hacked.

It's really nice see that some banks and sites have good policies. But most of sites and banks got absolutely horribly bad security. Afaik, that's one of the best ones I have seen this far.

It's especially important that part of target account is used to generate authentication verification key. Because using static or non-content sensitive confirmation codes is useless.

Exactly - because all of those solutions do not take into the account the possible active keylogger which might interfere with the "authentication code". In fact I think here in Belgium there was an incident where chunks of money were stolen from people.

I see what one of the commenters mentioned about the "extra gadget" - but I usually make internet payments at home - so no need to drag this gadget really. Plus, in theory I can use my friends' one - the gadgets are absolutely identical; the "something I have" part is on the card itself, which is in my wallet.

That's an interesting idea. Unfortunately it looks like you can comply with all the rules in his banks section by having an 8-digit password, which is conveniently the number of digits in a birth date.

So presumably they don't currently optimise for mutual incompatibility. Quick, file a patent. :)

"Quick, file a patent. :)"

Please file a patent and refuse to license the technology to anybody. :P

oh come on, you know that's not why they have these rules.

What you say may be true, but the banks only enjoy this 'feature' by coincidence.

There is a (mildly) compelling reason for every bank to have a stupid password rule...

Patrick, I think you're giving banks much more credit than they deserve. They are slow-moving monoliths that only respond to security issues when their profits noticeably drop.

Edit: And that's probably a smart tactic, as they aren't getting sidetracked from their primary mission of generating revenue.

Or the bank could just issue a secure password (or better yet, a list of one-time passwords) for the user. No need for silly rules, and probably much more secure than letting sixpack joe pick his own password.

Banks don't optimize for security, they optimize for profits. Picking passwords for users would be more secure, but it would also disincentivize use of the website and cause a huge spike in support requests.

People on the phone are expensive. (I'm unaware of exact numbers for the banking industry, but based on figures for my first-and-only CSR job, I'd guesstimate in the vicinity of $8 to do a password reset in the US and $2 in India. Given that the median retail checking account is only worth about $100 a year this is not very sustainable.)

Web banking is the best thing that ever happened to cost control for retail accounts and one of the highest ROI channels for getting more business.

Any suggestion for increasing security which results in banks losing money is probably a non-starter. (Not uniquely true for banks: many of the "Wouldn't it be grand if the entire world simultaneously adopted $LOGIN_TECHNOLOGY_FOO" thoughts ask businesses to spend money to solve problems that they do not actually have.)

Why do you think that bank-issued passwords would either disincentivize use of web banking or cause more support requests than the current convoluted systems?

> makepasswd

4igNxz1g

I believe that substantially less than 5% of Americans with a banking account would either a) recall or b) have recorded that when asked for it two weeks later. I have no citation for this other than "I have spent the last couple of years helping people log into their Googles and they frequently volunteer their passwords to me, often in the form 'My password is either kittens or kittens1 or kittens!' They overwhelmingly care about things in life other than computers, password security, and password security on their computers."

I realised a while ago that the most problematic logins for me were the ones with the most onerous password requirements. OK, I know this isn't great, but I do reuse passwords. The ones I care about least have the least adherence to good security practices, because it so vastly improves the user experience for me. Other solutions have been tried and cause more problems than they solve.

Between news sites like HN, content sites like BBC iPlayer, Facebook / LinkedIn / Twitter, eBay, different financial services websites, multiple email accounts, various topic specialist forums, standard and admin logins for each of the three computers I personally own, database server root passwords...... There's just far, far too many for me to be able to tie a unique password to each that complies with their length and character mix standards (and, in some cases, their re-use policies), particularly when the login page (sensibly) won't remind me what their particular complex requirements are.

I'm not at all convinced the end result of their aggressive requirements is more secure. Several of them I end up using the password reset function waaaay more than 50% of the time because it's enormously easier than memorising their particular onerous code.

Try something like 1Password, completely set me free of this stuff.

I'm willing to be persuaded, but I'm currently using two different machines, each with two different browsers open, and this is a relatively light usage case... It's a remarkably complex problem.

1Password can sync between multiple machines via Dropbox. I'm not sure about other OS, but on a Mac there is a browser plugin for Safari, Firefox and Chrome (and a companion iOS/Android app).

I've been using 1Passw[or]d since 2007, and literally all my passwords are uniquely generated (including server root passwords, database root, etc.) At one point I'm a bit scared if I ever lost the database, I'd lost access to all websites forever (because I don't even "know" my email password).

What about when I'm on [not-my-machine-in-a-coffee-lounge]

Well, you can still retrieve passwords from iPhone/Android apps, or in worse case, 1Password Web UI right from Dropbox web interface.

If you're using this 1Password for everything, how do you log in to your Dropbox?

Assuming you have a passphrase for Dropbox, as well; then, I didn't know it had a web ui, and that ~does~ make things convenient --- assuming SSL or similar for security.

I don't use (no longer use) Dropbox. 1Password database is synced to my phone via Wi-Fi, and I always have my phone with me so it never really a problem. If I ever leave my phone elsewhere, then I've got a bigger problem anyway.

Dropbox Web UI is just a HTML implementation of 1Password (read-only) sitting in your disk, so its HTTP security depends onto Dropbox (or whatever sync service you use) rather than 1Password itself.

If banks would supply the password on paper, then that issue would go away for most people. And if the bank would use OTP then supplying passwords on paper slip is a natural solution. I know that that kind of solution works even for computer illiterate people, as most, if not all web banks around here use OTP.

> If banks would supply the password on paper, then that issue would go away for most people. And if the bank would use OTP then supplying passwords on paper slip is a natural solution.

So you have to get a new paper slip every time you log in? How would the logistics of this work? If you have to go to your bank / wait for physical mail on every login, then the convenience of online banking goes away, doesn't it? (Or would you get a collection of them? Then, if you're like me, you'd lose that; and you'd be right back at the inconvenience, while someone else has temporarily unfettered access to your account.)

My bank gives a three times folded, credit-card sized password-card, and mail automatically a new one when you are about 2/3 through it. As it is credit-card sized, it can conveniently be stored in wallet, and thus losing it isn't much of an issue.

Unfortunately, I left such services due to this. It makes me think their system security is poor and asking to be broken into. No matter what 'security' marketing speak they use, I'll assume they have a similar if not same password policy for their IT department.

Much like how they're trying to save money, it's expensive for me to spend time trying to get my money back. Especially since they want to minimise support costs.

Edit: They should provide an option for power users to give an impression of 'strong secure access' while allowing 'secure convenient access' for other users. I've never seen this option before.

> Banks don't optimize for security, they optimize for profits.

So true, and to them "profits" often means "user convenience" long before "user security". I've talked about it here before so this time I'll just post a link to my story about the time my bank reset all its users' passwords to be equal to their usernames (intentionally!):

http://www.blahedo.org/blog/archives/000836.html

Deutsche Bank does this for online transactions. All your purchases and, if I remember correctly, bank to bank transfers require you to refer to a sheet of TAN numbers that is mailed to you when you open an account. It was surprisingly annoying at first but I got used to it.

These lists of TAN [1] numbers are phased out everywhere around me. They usually were hard to carry with you (just as a token, but more easy to destroy), had usability problems:

- Ordered lists: You could only use a number that followed the last used one. So if you had 10 numbers and used the 9th by accident, all previous were void. Forgetting to cross out the used numbers lead to annoyance and the 'dammit, guess I used that number already' factor decreased security (someone could've used the next TAN on your list and you'd ignore the error and think it was your fault)

- A list with columns/rows: The server would know about your 'state' and ask you for a TAN in a specific location. Think of copy protection around the time of Monkey Island.. Progress in a couple of ways, but finicky.

- You had to manage the list to make sure that you don't run out of numbers (the second 'solution' above could help a little, but if you planned to do 10 transaction a day and had only 9 digits left: Bad luck).

Right now, as others said already, you're using your direct debit card with a chip inside combined with a tiny TAN generator that looks like one of these crappy currency calculators. You enter your transaction (you already logged in before, with or without a TAN), the server tells you to enter a checksum (parts of it are clearly identifiable as information that you just entered) into your device w/ the direct debit card inserted to receive a one-time only TAN. Done.

A mobile option is usually present (my bank asks me everytime I log in if I want to use TANs generated by that gadget or being sent to my mobile number), but I actually prefer the other option.

1: https://en.wikipedia.org/wiki/Transaction_authentication_num...

There is a (mildly) compelling reason for every bank to have a stupid password rule which is mutually incompatible with every site in existence

But in my (personal, not professional) experience, they're not mutually incompatible. The bank and credit-card sites all restrict users to short, weak passwords, and it would be perfectly possible for me to use the same password on many of them.

Actually the main reason I have seen in practice is that banks still use a lot of legacy software in their core banking systems and many of the green screen mainframe programs have things like maximum password length of 10 characters or no punctuation (alphanumeric allowed). Of course eminently solvable but still surprisingly common.

I always thought it was done this way to avoid attacks such as XSS, SQL injection and so on. Free text fields are hard to validate and the authentication is usually a very sensitive feature! It seems to be the easy way to be safe (from the developer point of view).

Why would you need to worry about these at all? The password is supposed to be given to bcrypt, and the result from bcrypt is something that's usually not suitable for attacks on anything. So yeah, it may be sensitive, if you store plaintext passwords, but then that'll be the least of your worries.

This is why I use the longest password I can on these sites. If they're going to force me to use lowercase letters and numbers, I'm going to use 20 of them.

Which is fantastic when I have to read said password back to them over the phone.

Reply on news.ycombinator.com