Hacker News Reader

Comment by cddotdotslash | Hacker News Reader

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."

Points for thinking on his feet?

View on HN

"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.

10/10 for a devil's advocate answer.

Why 8? IIRC it is now recommended to do 10-12 (at a minimum) and since it's autogenerated, might as well make it 20+chars if the site will accept it.

Also, you are assuming that Schwab rate-limits login attempts. Given their dismal password policy, do you think that's a safe/reasonable assumption?

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)

you know, for security.

Oddly, their password field is limited by size, but their username isn't. I have a 30 digit random character username.

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.

Not like any of those things are hard to find.

Reply on news.ycombinator.com