Schwab password policies and two factor authentication
jeremytunnell.com
jeremytunnell.com
Representative: "One of the things we were trying to do with these passwords was make them different from other providers. So we know that they allow multiple character types, and are case-sensitive, so we decided to make them different. That way, you can't use the same password you've used elsewhere and it kind of forces you to come up with a new one."
Me: "...that is... I can't even explain how terrible that is."
Representative: "Well, Schwab does care about your security and as far as the 8-character limitation goes, the reason you can enter any arbitrary text afterwards is so that if someone is looking over you shoulder they can't tell that it only accepts 8."
Points for thinking on his feet?
* Google: no restrictions, as far as I could tell.
* Apple: password not accepted because it MUST contain at least one uppercase letter.
Of course, simply knowing that one of the characters MUST be an uppercase letter significantly decreases the number of combinations available
The main problem with restrictions like that is that it complicates the UX by requiring somebody to tweak their password manager's generator or its output to match the bogus restriction.
Assuming a 10 character password, there are 1.07 × 10^19 combinations without the restriction, 3.5 × 10^18 combinations with the restriction.
If we're dealing with a 24 character password, like my password manager slings out, it's 4.7 × 10^45 vs 1.5 × 10^45.
As you can see, it definitely reduces the keyspace, but when you look at the overall impact it's rather small.
you know, for security.
Maybe the best countermeasure would be to match users passwords against a dictionary,
Not like any of those things are hard to find.
Except it is public knowledge that there is an 8-character limit. Very basic footprinting would make it clear to only pay attention to the first 8 characters.
But in the case they see the full thing, they would write in down, go to try it, maybe type out the whole thing without even noticing there was a restriction, type ok, and bam there in. If they do notice the password could only hold 8 chars, what are the odds they wouldn't try what they have for the hell of it?
The dude must have been talking out of his behind.
If an attacker already has access to the password hashes, then yes, they can brute force any 8 character case-insensitive password easily.
However, a brute force "try to login to their site" attack isn't feasible without hitting a rate limit or alarm: (26+10)^8 = 2.8*10^12 is still a lot of attempts to login to an account.
The weakness to this model is the password. It is easiest to guess your password if it was the same one on your Sony account (i.e. leaked). However, if you're forced to pick a unique password just for Schwab, it's immune from the most common [citation needed] attack on passwords. Also, it makes the Schwab password useless for hacking other databases, making user passwords a less valuable target for hackers.
If the tradeoffs are worth it: I have no idea, but it's not without merits. I personally like using a password manager with 2-factor authentication and generating all new random PWs for my accounts. I generally don't use more than 8-character passwords, since they're isolated from each other anyways. I would be negligibly less secure using this with Schwabs constraints than other sites, as the security lies in isolating passwords. (I use https://lastpass.com/)
Also, you are assuming that Schwab rate-limits login attempts. Given their dismal password policy, do you think that's a safe/reasonable assumption?
I'll give you points for honesty on the [citation needed], but your entire argument hinges on this point and there's no a priori reason to follow your assumption.
Moreover, your idea of each website having a unique set of constraints to force unique passwords scales horribly from a user perspective.
10/10 for a devil's advocate answer.
They didn't do anything, so I sent around the article and pretty much every publication I sent it to ran with it. After that they took down the login page for about nine hours and brought it back up with brute force protection.
https://kev.inburke.com/kevin/open-season-on-virgin-mobile-c...
This sounds like a symptom of the multilayered bureaucracy that often goes on in banks and similar institutions - a change to the UI to add something as simple as an extra field for the token code, and the changes required to hook it up to the backend, might have been accompanied by so much "enterprisey" management red-tape cruft (specification writing, approval documents, approval meetings, meetings for scheduling meetings - I wish I was joking, etc.) that it made the programmers find creative ways around the system.
At the least, if I were forced to concatenate fields, I'd use a separator that couldn't occur in either one, like a comma or something else that their password policy didn't allow... but then again, I wouldn't be surprised if something else in their system would reject that.
Why? All of these big banks and investment houses have holdings in the neighborhood of billions of dollars. Like billions in actual cash. If they are so vulnerable and insecure, why aren't all of the hackers targeting them, with their potential upside of billions of dollars in cash, and instead target little web apps to steal some credit card numbers or user data, worth tens of thousands to maybe a few million on black markets? Think about how much effort we've seen put towards stealing cool Twitter handles and other such trivial things. Does anybody really believe that there aren't many more people working much harder to hack banks, with their billion dollar paydays?
They may not be the greatest on password handling, but the evidence suggests that they have a much more healthy security culture overall than your average internet startup. Apparently, they are worlds better at making their systems secure enough that nobody can steal these user databases in the first place. They most likely also have a pile of fraud detection and validation on account activity, especially anything involving moving significant amounts of money out of the accounts. They are probably in the right on this - what's the point in building a perfect lock for the front door if, once an attacker gets in, they can transfer the whole balance to a Russian bank and nobody will notice? Consider how, with some well-publicized recent hacks, you can apparently do anything at all once you get through that front door at most major tech companies.
I'll happily change my tune if any of these banks get hacked and lose big money. Until then, maybe we should ask these banks how they get it so right overall instead of worrying and hassling them about how long their passwords are and how they're storing them.
Apple can't seem to protect their Apple IDs or iCloud data from determined attackers. Amazon and GoDaddy have given over total control of user's accounts to pretty simple social engineering attacks, both giving the attackers the keys to the castle. None of these attackers seem to have much in the way of funding or organization, and the stolen data doesn't seem to monetize terribly well. Do you think these companies would be able to keep trillions of dollars of their customers' money safe from attackers? Chase seems to be able to. Maybe the tech companies should take a few lessons from them.
[0] http://www.wikiwand.com/en/JPMorgan_Chase#/Financial_data
[1] http://www.marketwatch.com/investing/stock/jpm/financials/ba...
A system where you can pull money by knowing a set of "secret" numbers shared with every entity an account holder has ever done business with is just insane to begin with.
We rely on reading transactions after the fact looking for red flags. You can beat the filters sometimes by running millions of credit cards. You can't really expect to move $100 billion from an investment bank to your checking account without anyone noticing and using their central authority to reverse the transaction.
I don't think we even have a really solid idea what a logically secure financial system would look like, how to build it, or if it's practical. Bitcoin seems to be the closest and most practical thing we have so far to that. While Bitcoin is cool and interesting in a lot of ways, the practical security of it leaves much to be desired, based on the observed results so far.
And to steal from a bank account? You'd need another bank account! Bank accounts require you to put up your own personal info, which is a huge barrier for Off shore hackers to overcome
With computer security, you have to obsess over the minutia because a single vulnerability is all it takes to defeat the system.
I'd say that more than obsessing over the minutia, you have to obsess over the entirety of the system as used in practice, of which the authentication system is only a small part. I don't know finance that well so I'm kinda spitballing here, but stuff like exactly how the system that approves transactions actually communicates with the systems authorized to actually move money, what types of transactions are allowed and to where, what kind of checking is done against various transaction types, how to correlate to the user's activity history. If user normally connects from Atlanta and uses an online billpay system to send checks to a handful of companies, be very suspicious and probably flag and review the transaction if somebody suddenly logs in from a different address and requests a wire transaction to a foreign bank, etc.
The evidence (lack of constant ripoffs) suggests that they are quite good indeed at obsessing over the minutia of the rest of the system. This allows them to get away with authentication practices that are, depending on your point of view, somewhere between actively awful and bending over well past backwards to make things simpler and less error-prone for unsophisticated users. Got any idea how many users with 7-figure or more account balances still want to login on their flip-phones, bank online with IE6 on WinXP, use their account even after they epically screw up their password or their TFA key, etc? Neither do I, but I bet it's a lot higher than any of us would like.
He never replied.
I went to far as to get in contact with senior staff members at Schwab to alert them to the issue, and got a pretty condescending response.
I mentioned it to a friend at a burrito truck outside the Mozilla office, and soon found out it was a top post on /r/personalfinance.
I got a call from Schwab shortly after that. But the rep I talked to just said they were "working on" allowing more characters in the password.
I must say though, this post does a great job detailing their 2F solution. I never set it up since it seemed like wearing a fishnet condom given the rest of their security, so I never got to see how bad it is.
...However, the standard explicitly permits any other password requirement of the same or greater entropy.
...However, these requirements do not apply to consumer accounts at all (!). As far as I can tell, PCI-DSS actually has no requirements whatsoever for safeguarding of consumer user accounts. The more you know, the more you worry.
The thing is, you never get a sense of how bad legacy code can be at restricting options in reforming sanity until you have worked on such sites.
It took me about 5 months to restore sanity to one codebase with a bunch of problems regarding encryption and passwords. Fortunately security was a priority, and not just security checkboxes in PCI requirements but real security. But it wasn't cheap and it wasn't easy, and we ran into a lot of unpleasant surprises along the way.
Looking at this the chance is that you have tons of legacy code, and these fit together in not very nice ways. People are afraid to change things because of PCI requirements, security scan results, etc. And the cost of fixing things my be very high. In these cases, I can imagine a "don't rock the boat" mentality developing and a large part of security-critical code becoming effectively untouchable.
Then he doesn't have an eBay or PayPal token, because they both do it. Or rather, it is an option to do it that way, in order to skip over the "submit, enter token, submit" workflow.
https://www.paypal.com/us/webapps/helpcenter/helphub/article...
They have been frustratingly slow in implementing features like linking external bank accounts using trial deposits instead of mailing them a voided check from the external account.
Their slowness to adopt these new features has meant that if you got access to the online account, there wasn't much you could do as a third party that moved money out of the already linked accounts of the victim. You could cause headaches or buy/sell securities but not access the money easily. And if you did link an account or add a biller the victim would get an email.
Things have probably changed recently since I think you can link external accounts now, and there's probably a way to send yourself a check as a bill payment.
Totally not an excuse though.
Note:
I was fooled by the password length as well. Sometimes I would hit what I thought was the wrong last few letters on my phone keyboard yet the password would still work somehow. Turns out you can just type the first eight and be done.
Hmmm. Where have we heard that before? Yes, Sony!!! There's probably a better link but here is the first one I found:[1]
Back in 2007, Jason Spaltro, then the executive
director of information security at Sony Pictures
Entertainment, was shockingly cavalier about
security in an interview with CIO Magazine.
He said it was a “valid business decision to
accept the risk” of a security breach, and that
he wouldn’t invest $10 million to avoid a
possible $1 million loss.
[1] http://fusion.net/story/31469/sony-pictures-hack-was-a-long-...
http://www.schwab.com/public/schwab/nn/legal_compliance/schw...
When payouts on this security guarantee begin to become a meaningful burden, I am sure Schwab will improve their security practices.
"Schwab takes online security very seriously, and all clients are protected against fraud with our SchwabSafe guarantee. This guarantee is available to review online at www.schwab.com/schwabsafe.
"I reviewed the website you referenced in your email, but this is well outside my area of expertise. To discuss these items, I would suggest you contact our Technology Support Group at the Help Desk. Their number is 800-433-9196."
Uh, no. I'm not going to sit on the phone waiting to tell your Help Desk about why they shouldn't store my password in their DB; that's your fuckin job. I'm much more inclined to spend that hour and a half moving my accounts somewhere secure.
The banking system functions largely on the choice, application and integration of technology, and banking is more of a technology business than just about any other. And let's be fair here - Schwab is not a bank, and even among investment firms is an outlier with the noted bad practices.
They don't behave like Google or Facebook. Their DNA is not technical.
Do you have any informed opinions on Simple?
It's not much but it was all I could come up with.
My wife wants to use the Schwab app to deposit checks on her phone but I don't trust their security. One lost phone could lead to our retirement funds being transferred to Belize (or wherever).
Schwab's standard response was 1) to assure me that they had "intelligent" fraud monitoring systems on their backend and 2) to offer me a hard token, which would have been a pain and may have caused issues with Mint.
You'll be back to Schwab before you know it. TD are beyond awful. Schwab have pretty much the best customer service going.
They let you choose a random user id, as in, change the user id whenever you want. I bet you the security guys over at Schwab are using that as a reason to not improve password options. I can see the argument being - "The idiotic password limitations are not a big deal because of the random userids".
How expensive is too expensive for some of the richest companies in the world?
"Acceptable risk" is the usual term, I believe.
Legacy code written quickly in 1998 and not replaced yet?
I wouldn't voluntarily post my bank account credentials on the internet, but at the end of the day, the security of an online banking account just doesn't matter very much.
The security of the transaction mechanisms do, sure, but that's got little to do with online banking passwords.
Which sort of implies to me that they should find a way to fix it before they have a big breach.
If nothing else, the fact that they've been warned repeatedly and done nothing could be pretty compelling if there was ever litigation over losses.
For example, I could imagine someone successfully disavowing a trade at Schwab because they don't enforce the password authentication they claim to, and thus can't convincingly claim that the trader was in fact the account owner.
Edit: forgot to mention that the passwords are case insensitive!!!!!!
It is possible there are more than one schwab interfaces that behave differently. I have two entry points. One for just 401k (https://www.schwabplan.com). That one has long case-sensitive passwords.
The brokerage account(https://client.schwab.com) is short and case-insentive
# This should work for any such service:
Service.set_password('MyPassword')
Service.verify('MyPassword')
# These fail if a case-sensitive service
Service.verify('mypassword')
Service.verify('MYPASSWORD')
# They drop characters if these work:
Service.verify('My')
Service.verify('MyVoice')
# I hope not: 'mypassword' phone pad digits
Service.verify(6972779673)
# Even worse, if they might store only the first digits:
Service.verify(6972)
Then I got phone calls from them asking why I hadn't finished, so I had to explain to a person that clearly wasn't technical (not his fault, of course), that his company had no idea what they were doing security wise.
Maybe they finally fixed it though. I can only hope.
Schwab has "...a system which locks you out if you guess the [username,password] combination incorrectly more than twice.."
Schwab can improve your security via Verisign and verbal passwords, but you have to ask for it: "... Schwab has several additional (optional) verification methods."
http://www.marottaonmoney.com/schwab-verisign-security-measu...
I may be wrong, but I think user IDs can be longer than 8 characters too which makes this all even worse.
LinkedIn did something similar with having to append your auth token to the end of your password, but they actually checked the token AFAIK.
Not saying that this is a good idea, but there are some benefits for appending the token.
As it stands, there's no need to confuse existing users. You just need a separate pathway to activate the token.
THEN you just ask for the token as a step two in the login process. That's actually how Schwab handles things right now.
As expected, Schwab isn't the only perpetrator of bad two-factor auth. I think PayPal still DOES NOT support two-factor auth on their mobile clients.
Shameless plug of my blog posts about Paypal's terrible two factor auth:
You don't need a third field. On mobile, if you pass the password auth, you go to a new screen and bring up a number pad and ask the user to wait for the text message. It's pretty smooth. Much smoother than the LinkedIn flow I described above. If you don't have 2-factor auth after passing the password auth, you just go right to the app.
I documented my frustrations here in case you want to see: http://mark.gg/2013/07/17/linkedin-2.5-factor-authentication...
LinkedIn already fixed this, but it's quite shameful they even let this out into the wild. :/
It's a terrible UX though. I wrote a blog post with some images about it if you want to see what it looks like: http://mark.gg/2013/07/17/linkedin-2.5-factor-authentication...
(I travel a lot for work so I get reimbursement checks frequently)
OpSec 101: replace that sentence with "Like probably millions of people I have a Schwab brokerage account, and that account holds just a few bucks of play money to try out trading strategies."
I ended up calling support to figure out how to set things up.
Sadly, I expect it will change only if there was some embarrassing large scale attack that is subsequently publicized.
If someone stole a database from a provider that implements passwords correctly, the best they could do is get some low-hanging fruit passwords.
I would be even more disheartened if customer complaints and an article in Ars can't get this fixed, but someone "passing it on to a contact" could. It's disgusting that this is how they've handled it. I minimize how much money I keep with them and will be closing the account when I get back to the States.
Not being able to recall my password, I was able to reset it by supplying only my mother's maiden name and my date of birth.
Um.
It sound like DES encryption stored directly in the database. (This is pure speculation of course) This alone is a huge red flag. Adding the fact that the 2 factor auth. is broken is not a good news.
The point of the article was that Schwab's login security is so broken, even when you do all of the right things yourself, Schwab's implementation of passwords and 2-factor auth may make you think that everything worked when it didn't.
It is my opinion that someone who had read the article, had a Schwab account, and who had enabled 2-factor auth for that account would have responded to or added to the experiences expressed by Jeremy Tunnell. But there are no words in acconrad's post that leads me to believe that they read the article before posting, as it basically amounts to, "When I contacted them about crappy password security, I ended up with a 2-factor fob. You should get one too." ... which is great advice for any system offering 2-factor auth, but it basically ignores the whole purpose of the article, which was to point out how utterly broken the entire process is.
Could I be wrong and acconrad actually read the article first? Sure. But I asked a question which embodied my opinion on the matter, based on what I read up until that point. And so far, I've not seen any evidence to the contrary to change my belief that acconrad commented without reading the article (your reply doesn't contain information/evidence that is applicable to the question that I asked, as I have at no point offered an opinion that you are responding to).
But I've spent entirely too long replying, and won't be following up further. Good day.
Q: "Your secure banking portal has critical vulnerability!"
A: "Did you try to reboot your computer?"
I was kind of speechless, but I said, no, that's ok, I've decided I don't need help anymore, and shortly thereafter I closed all of my accounts. I've moved to a smaller firm where I've specifically asked for my accounts to be inaccessible from the internet in any way, and I have a financial advisor assigned. If I need something done, I can call him or his assistant. I can't make big financial moves at the click of a button, which suits me just fine.