We need some sort of interenet security reformation. This is even more ridiculous than when the Chase mobile banking app for Android didn't check if SSL certs were authentic before sending credentials.
I've been using Schwab for almost 5 years and haven't noticed the password limitation until about 2 years ago. My password is pretty lengthy, so when I mistyped the last letter and pressed enter, I expected an error message. Instead, Schwab logged me in. I investigated a bit and ended up contacting Schwab about the "vulnerability". I remember someone quite high up responding saying they were aware of the length limit but that they lock you out after 3 failed password attempts. I didn't validate the claim, but I felt content and moved on.
I had a similar experience with Southwest Airlines. They limit their passwords to something absurdly short, and it turned out I'd never noticed - I always typed what I thought was the password, but it was actually ignoring all of it but the first 8 characters even though I typed more in every time. I don't think it's quite as bad as Schwab, but I don't understand why doing passwords so wrong is so widespread.
If someone managed to steal a database of credentials from Schwab, they could possibly decrypt the passwords (all these limitations clearly point to them not hashing properly).
If someone stole a database from a provider that implements passwords correctly, the best they could do is get some low-hanging fruit passwords.
This has been a problem for years that they refuse to fix. The legacy password thing (Strike one) is bullshit, they could just force everyone to update their passwords when they implement a properly designed system.
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.
Quite shameful. Fortunately, I only use Schwab because of their awesome checking account that covers ATM fees. Definitely won't put more of my assets in there until they get their act together.
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.
Convenience for the user (no need to move to a different field) and UI advantages (no need for an third field which might make the form look complicated and confuse users who don't have 2FA activated.
Not saying that this is a good idea, but there are some benefits for appending the token.
Definitely not more convenient for users in all cases. LinkedIn did something similar. When they told me to append my code to the end of my password and I click on the password field, my password would be wiped away so I'd have to type in my password AGAIN and then add the security token to the end of it.
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.
There are other banks that offer accounts with similar benefits plus the benefit of having physical branches. TD premier checking is one, if you're fine with keeping a minimum balance.
I also only keep a bit in it for travel. The rest is in a different account. When I want to deposit funds, I write myself a check from my credit union, or deposit a reimbursement check.
(I travel a lot for work so I get reimbursement checks frequently)
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.
I created an account a while ago, added the requisite $1, and promptly never used it again, largely because they didn't offer savings accounts (and still don't seem to).
I filed a support ticket about the password length. They told me it was due to "government standards" and they would reevaluate after a new standard came out. I didn't inquire further into this obvious BS. They provide a good service otherwise so it's strange that they have this blind spot.
My guess would be that by "government standards" they were referring to PCI-DSS (actually an industry group standard), which in the current version requires passwords of at least 7 characters and with at least letters and numbers (PCI-DSS v3.0 8.2.3).
...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.
Im confused, are you verifying that the passwords are or are not case sensitive? Mine is certainly case sensitive (watch me get hacked now, 8 characers, one is capital!)
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.
"Case sensitive" means that it matters whether you keep characters matching the same case. So, let's imagine a hypothetical service:
# This should work for any such service:
Service.set_password('MyPassword')
Service.verify('MyPassword')
Logging in with the mixed-case password (which should, of course, work) does not tell us anything about whether it's case sensitive. However, if alternate-case verisons of your passwords work, your service has case insensitive password:
# These fail if a case-sensitive service
Service.verify('mypassword')
Service.verify('MYPASSWORD')
If we can give it either too many or too few characters, then they are likely truncating your password before storing/testing it:
# They drop characters if these work:
Service.verify('My')
Service.verify('MyVoice')
Edit: And, in case they are trying to be nice and allow you to log in with your phone, they might do something lame like store your password as the numbers-you-would-type, rather than the actual characters, in which case this might work:
# I hope not: 'mypassword' phone pad digits
Service.verify(6972779673)
# Even worse, if they might store only the first digits:
Service.verify(6972)
Apologies if I've made any typos, but I hope that clarifies how one might verify that passwords are treated as case sensitive or not.
I have called and complained many times about their password policies.
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".
Apparently they insure you against someone breaking into your account, but this is clearly the case of a bunch of old boys who don't understand tech being in charge.
I recently filled out a support ticket concerning password policies too, after opening an account. I received a rather absurd reply and decided not to transfer any of my money to them.
To activate my newly received token, I was instructed to go to the homepage and append the six digit token code onto the end of my password during a login attempt.
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.
I complained to Schwab about their password policies numerous times over the 3 years I was a bank/brokerage customer. A few months ago I finally moved my accounts to TD.
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.
Not that this is an excuse, but keep in mind that Schwab probably has had the mentality that a compromise of a user's online account, while bad, is not the end of the world.
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.
> Schwab probably has had the mentality that a compromise of a user's online account, while bad, is not the end of the world
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.
Has anyone heard recently about how that's working out for them? :)
Some of their competitors are just as bad. I remember I started to sign up for a TD Ameritrade account a few years ago, but when the password "requirements" came up (which were very similar), it was clear that they were probably storing passwords as plaintext, so I stopped.
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.
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.
User friendliness. FB did something similar where they'd store several versions of your password. That way they could tell if you had caps lock on or other problems.
You really used facebook as a best practices example? Where is the source code of facebook's function that deals with case insensitive passwords? How can you be sure such source code is actually being used in production? It's as good as plaintext without any of those assurances...
After receiving unsatisfactory responses from my local Schwab rep here in New York and the customer service staff, I complained to Schwab's CISO, Bashar Abouseido <bashar.abouseido@schwab.com>, on September 1.
why did you remove the headline part about their policies being CRIMINALLY TERRIBLE. yes, "comedic" might not be completely correct, it did describe the tone of the article: NOT GOOD.
anyone with money in a schwab account schould schip all their schillings home, and tell schwab to schuck it.
Schwab does let you enter your token code on a separate screen. If you enter your username and password (without appended token code), you'll get this screen:
https://www.flickr.com/photos/paul/16079572151/
You're correct, but that doesn't fix the first activation, which is what I wrote the post about. The real problem is that I thought I had two factor activated for months when I didn't.
It may be much worse than you think. Another large brokerage company I know of has similar password requirements. They also have a phone banking system, to use it you have to touch tone in your password. On a whim I tried entering the keypad version of my password on the website and surprise! it worked. Luckily for me there is zero customer liability for fraud on their retirement accounts.
"Like probably millions of people I have a Schwab brokerage account, and that account holds a good portion of my savings for retirement."
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."
Like many others, I just filed a support ticket as well. I'd like one of two outcomes: 1. A public response and plan from Schwab, or 2. An alternative bank/brokerage company that a) takes security seriously and b) is easy to move to.
"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.
I just called Schwab about this, and hand to whatever deity you believe in, this is what he told me:
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."
I love the arbitrary restrictions that all these sites come up with that ultimately make them less safe. Yesterday I was setting up some stuff for somebody who knows nothing
about tech. IIRC it went like this:
* 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
Let's not get crazy here: knowing that one of a variable number of characters is uppercase does decrease the keyspace, but it's definitely not a "significant" reduction.
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.
Agreed on password manager, but I still think the decrease is significant. I won't run my mouth further and might try to quantify that decrease over the holidays.
I like round numbers, so lets say that we've got 26 lowercase, 26 uppercase, 10 numbers, and 18 symbols, for a total pool of 80 character options. For our single lame character, you're stuck with 26. All calculations are rounded off to make them a bit less insane to read.
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.
In both cases, the decrease you quote is about sqrt(10). It does taper off when you do a 24 character password (which is about the range of what I would choose), but it's still 30%; 70% of a large number is a large number. Typical users are not so technical as to use a 24 character password and therefore, in an unsalted leak, after the rainbow tables stage, it makes it 30% easier to brute-force them (going by your numbers).
when I worked at Barclays (it was >10yrs ago now to be fair) the enforced password policy for our internal system was "4 ascii letters + 1 symbol + 4 digits" in that arrangement (ie: abcd!1234)
What actually matters is not the key space when it is so vast. Without these requirements: number, special char etc, the passwords used in practice would often just be dictionary words, and a dictionary is a much smaller key space.
Maybe the best countermeasure would be to match users passwords against a dictionary,
Yes, but I'll bet that they'll give you the username if you know the Social Security number and birthday of the user. Sometimes they ask me for the address on the account.
"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"
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.
Right it would only work if they happen to start looking at you type after you started typing, in which case they wouldn't have your full password any ways.
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.
This justification actually makes some sense to me (Software engineer familiar with crypto.)
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/)
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.
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.
Rate-limiting is important, and almost universally practiced, but it doesn't have anything to do with the problem with short passwords. When the password database inevitably gets hacked and uploaded to Pastebin, it's too late for rate limiting.
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."
126 comments
[ 4.7 ms ] story [ 168 ms ] threadSadly, 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.
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:
http://mark.gg/2014/10/22/paypal-and-delusions-of-grandeur/
http://mark.gg/2014/06/04/kicking-the-tires-with-paypal/
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)
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?
http://en.wikipedia.org/wiki/Sony_Bank
...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.
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
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".
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.
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 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]
Has anyone heard recently about how that's working out for them? :)[1] http://fusion.net/story/31469/sony-pictures-hack-was-a-long-...
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.
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.
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?
He never replied.
anyone with money in a schwab account schould schip all their schillings home, and tell schwab to schuck it.
I ended up calling support to figure out how to set things up.
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."
"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.
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.
Too bad you used a throwaway so we can't look out for you to avoid hiring you.
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...
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.