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."
"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.
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).
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,
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)
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.
I had pretty much the same experience with Virgin Mobile last year (passwords limited to 6 digits, no brute force protection). I finally told the guy I got escalated to that if they didn't do anything I'd call the NY Times, Consumerist, Gawker, CNET, Ars, etc and tell them about it.
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.
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've been coming to an opinion on these issues that may be unpopular with the tech crowd: The big banks have the right idea when it comes to security, and we are misguided at best with our obsession over the minutia of password handling.
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.
A substantial volume of low-level fraud occurs every day and is baked into the cost of doing business because that costs less than reengineering fundamentally insecure systems.
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.
There's some truth to all that, but I'd say it's kind of another point. We don't have and never really did have a logically secure finance system. We have a human-secured finance system instead, where for virtually every transaction, there is a human somewhere who has the power to review and reverse it. It seems clumsy to the programmer's mind, but it largely works pretty well.
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.
Excuse the short answer, with family for the evening. In short I think that the reason you see hackers target web startups and credit cards is because you can get away with it. Example - it's easy to use a credit card, buy something online, and have it shipped to a big office or apartment.
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
Hmm, looking at that, I'd say it more proves my point. At the top of their Wikipedia entry[0], it says that JPMorgan Chase has roughly 2.5 TRILLION in assets. According to this[1] site, 1.29 TRILLION in customer deposits. Hackers believed to be from Russia breached some of their systems and stole... drumroll please... customer names, addresses, phone numbers, and email addresses. There's stuff in there of value comparable to national economies, a mind-boggling amount of money, and they didn't get a penny of it. All they got was a glorified phone book.
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.
Did you finish the article? At the end the author claims that their two-factor authentication can be defeated by appending extra characters to your password. In other words, they have no two-factor authentication. This isn't a matter of differing points of view, this is objectively awful.
With computer security, you have to obsess over the minutia because a single vulnerability is all it takes to defeat the system.
I did, and that is a pretty epic screwup. But in the end, it seems that the cost of them screwing that up, aside from maybe a few techies cancelling their accounts, is zero.
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.
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.
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.
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.
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.
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.
Having worked on some major financial web sites (globally), including password code, I can say a few things that may be relevant.
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.
> I've never, ever seen this "append stuff onto your password" approach being used.
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.
It's worth noting that some of the two-factor systems that integrate with RADIUS also use this same method, where you can't control how the end system prompts users to authenticate.
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? :)
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 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).
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.
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.
Thanks for calling attention to this. I've been frustrated by it. One thing that I did was let LastPass generate 32 random characters for the password but used it to change the username. I depend on LastPass to remember that.
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).
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.
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.
Online banking is largely a read-only proposition. It's mostly for reading account activity. Some of the more forward-looking banks will even let you initiate ACH transfers, but generally sending money to a new recipient triggers a 2FA prompt (debit card number prompt, phone call, text) and several secondary notifications, with several days to say "that wasn't me" before the money is gone.
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.
I'm guessing that if they had a major breach because of this kind of idiocy, they'd find a way to fix it after the fact.
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.
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!)
"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.
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.
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.
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."
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.
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)
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.
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.
"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."
Fidelity had a similarly terrible password policy (6-12 characters, only letters and numbers). I complaining to their tech six months ago and got a stock "we're looking into it" answer. In the past month they've actually fixed the issue and now require 6 characters (upper case, lower case, number and symbol).
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.
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.
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.
I've also bemoaned Schwab's password policy. I reacted by changing my login ID to something nonsensical which would be difficult to guess or to associate with anyone's identity, let alone mine.
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...
I, too, complained months ago about the poor password protection. I immediately had them send me a 2-factor FOB. While it isn't a great solution, it's one I would ask for asap.
While I see your implied point, DrJosiah, the above commenter did not say that the authenticator was without issue. Moreover, the blog post did not attempt to prove that the 2 factor auth did not work IF configured properly, but that the UI was incredibly misleading when activating the token.
Go read the article (or the first 2 paragraphs even), then come back and read the comment.
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.
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.
It's really a shame they're so bad at all of this. I've had nothing but a fantastic experience when dealing with them for my Investing and Checking accounts.
I used to have my retirement accounts at Fidelity. One day I needed some assistance with something I was seeing on their web UI, so I called them up. The support person said (not an exact quote, but the gist), "in order to see what you're seeing, I'm going to need to log in as you. I need your permission in order to do that. Security precautions prevent me from being able to see your password, so I will need to change your password to a temporary password of '123456fidelity' to proceed. Is this ok?"
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.
Certainly less important than a financial institution, but I had the exact same experience calling Virgin America's support a few months ago when their then-new website would consistently error out every time I tried to book a flight.
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?