Hacker News Reader

Comment by OSButler | Hacker News Reader

A client once had an issue where his account got compromised and everything pointed to having his actual login details leaked. His password was something like his username plus an assortment of random characters. It turned out that the system his account was on basically ignored everything after the 8th character, so that you were able to login with the username as the password.

Also, during the early days of inline password generators, there were cases where the suggested password was incompatible with the associated system.

View on HN

There's a lot of crap out there: http://www.troyhunt.com/2011/01/whos-who-of-bad-password-pra...

It's common when there's a web interface bridging directly into a legacy mainframe system built in the 70s.

That's how you see things like "your password can't contain Q or Z" (it was originally a rotary phone-dial interface and ancient US phones didn't have Q or Z[0] — to say nothing of special characters, this means the system may also map letters (case-insensitively) to numbers grouped by 3… think your password is "fido"? it's actually encoded as 3436)

> Also, during the early days of inline password generators, there were cases where the suggested password was incompatible with the associated system.

That still happens to this day. There are still a ton of password forms out there which only accept very short alphanumeric-only passwords.

[0] https://upload.wikimedia.org/wikipedia/commons/7/7b/Rotarydi...

Try to create a password at Jet2.com. A Password like: "SuperSecretPassword!" gives you an error "Your password must be at least six characters or more and is case sensitive.". It's idiotic.

Oh yes, I'd almost forgotten about the misleading, unhelpful or downright incorrect error messages. It's also fun when account creation and login form don't use the same validation rules, so you can create an account but then you can't log into it.

Even major sites suffer from this. Netflix web UI allows 60 character passwords, but their Roku app and I believe the Xbox One app only allow 50 character passwords.

I ran into that once with my credit card company. I used a generator to create a maximum length password, only to discover that the Javascript managing the login had an off-by-one error and wouldn't accept that length. I was able to work around it through judicious use of browser inspection tools -- the change password page accepted it just fine.

I sent in a complaint and got something to the effect of "well, no one else reported it."

VirginMedia (large ISP in the UK) won't accept passwords longer than 10 characters. No spaces or special characters allowed, must contain a number, must start with a letter etc.

What is really frustrating about this is when I asked them why they reply "we've chosen these limits to make sure your online password is secure"

I can imagine your facepalm.. Wondering how many of these "up to N characters" rules are actually there because there is a `password CHAR(N)` DDL declaration for storing plaintext passwords...

I tend to set password fields to varchar(400), though it's encoding info and base64 hashes.

    encoding\options\base64-salt\base64-hash-of-normalized-utf8

I keep the encoding/options so it can be backwards compatible on change... when an encoding/options isn't the current when the user logs in, it will be re-encoded/saved in the current... this is so that security can be upgraded over time.

Run normalization on composite unicode characters & look-a-likes before encoding.

I do one thing some consider bad, which is strip leading/trailing whitespace which is more often a copy-paste error, not actual password entry.

Same with the Virgin Atlantic Flying Points site (usernames and passwords). Infuriating thing is the points are worth real money and can be transferred to other users so there is a real incentive to break in.

I guess it's a problem across the entire Virgin group of companies?

Additionally, if you contact their customer support via the form they used to provide they ask for your password, which is them presented back to you in plain text when they reply.

Quoting from a reply I had: "As there's no account password quoted on the form you’ve filled in I'm unable to go in to any account specifics."

"accountPassword: I'm not giving you my password"

> think your password is "fido"? it's actually encoded as 3436)

A form of hashing... ⸮

I enjoy seeding a random password generator with a bunch of non-ascii characters [1]. Often it fails telling me that I'm using unsupported characters, other times the form just doesn't return (or returns with a 5xx error), and even worse sometimes it lets me create the account but I can't login because they did something weird with those characters. I'd say less than 70% of sites let me login with one of these in my password...

At the very least try to use one of them (generally a simple alt-code works, the first smiley face is just alt+1), it's a pretty good indicator of which sites are mucking with your passwords.

[1]•◘○◙►◄↕‼¶§▬↨↑↓

Edit: Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!

> Turns out HN strips a bunch of them, so my smilies and a bunch of others didn't make the cut!

Which is exactly why I'd be wary of such clever password schemes on any account I cared about.

The first "smiley face" on ALT-1 is actually the ASCII character SOH "start of heading"; many things that might otherwise accept Unicode will properly filter that out because ASCII control codes are illegal in a wide variety of otherwise-accepting contexts.

But it is a great QA check on any text field, which should either cleanly reject it in some manner [1] XOR accept it and process it "correctly" for whatever that means locally, but not something in between.

[1]: A lot of Unicode processing nowadays puts in the Unicode replacement character for unknown characters, but for the ASCII control codes I'd say you've often got a solid security case to say "Someone's just trying to screw with the system, we'll just filter it out entirely" for them. Excepting the ones we still use, basically \r \n \t, there's not much reason to keep them. (Think twice about \v "vertical tab" and think three times about letting \b "backspace"s through. Inconsistent behaviors by various layers of code are scary.)

It makes sense that control characters are removed (or replaced). I didn't know the ALT-1 was SOH, so that's good to know. (I guess I'm showing my age a bit there)

Thanks for the info!

If you call in to your fidelity account, they ask you to type in your username and password with the keypad to authenticate yourself. I haven't given it much thought, so perhaps I'm wrong, but this struck me as probably based on some dicey insecure backend implementation.

More likely it is to prevent your having to say your password to the person on the phone. This protects you from a malicious bank employee.

That'd certainly make sense — a lot of what we see now are fossils like that, frozen in the amber of legacy systems.

That would be a reasonable precaution in the era before recording devices became cheap, tiny and ubiquitous (or capable of doing signal processing in real-time) – just as changing passwords monthly made more sense in the 1970s when shoulder-surfing was the major threat and lack of remote access throttled guessing rates even more than slow CPUs. (Repeat for plastic ID cards before you could buy a printer at Costco, etc.)

Right, but my point is the backend to make this work must be terribly insecure. I just did some reading, and apparently they take your password and just store the keypad equivalent (or more likely, a hash thereof). So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

> they take your password and just store the keypad equivalent (or more likely, a hash thereof)

That's… not exactly more likely. These are commonly systems predating the internet, from a time when connected networks were trade-specific and Very Expensive, storage security was a lesser concern (and CPU-expensive) when the system could only be accessed on dedicated lines only accessible to employees.

> So you can login in to the website with your original password, the keypad mapping of that password, or any text password that maps to the same keypad digit mapping, and they all work.

I'd have to see this to believe it. I would hope that they would at least store it as two separate entries, and only use the phone one during the phone process. And the person on the phone will likely still ask you some less-sensitive verification questions.

I had googled just now and read that somewhere else, but you are right, I just tested it, and it does not work as I described on the website itself.

I don't know what Fidelity does, but I work at a bank and if we were to implement such a feature we handle it securely. When you set your password we store a hash of the password, but we also store a hash of the keypad version of your password.

So logins to the website still use the full character set -- only logins via the phone are verified against the keypad mapping. That one has less entropy (because of the reduced character set) but attempts to brute-force it will QUICKLY be recognized and stopped, since each attempt is visible to a human being who is handling the phone call.

That's how Schwab.com implements passwords. 8 characters max. For life savings brokerage accounts.

Swedbank in Sweden have a feature where you can access an accounts entire balance by generating random CC#'s for online shopping and this service is protected by your social security number, a 6 character password, a-z, 0-9 and no special characters allowed.

They've had this for at least 6 years now, maybe longer. Early on when I e-mailed them about it they simply stated that it's not their service, in other words; out-sourced.

Swedbank also requires two-factor authentication. You can bypasss this by calling them - they only ask for 1 thing to authenticate you. Two-factor authentication is rather useless if you can just bypass it like that.

Yes, and I had no idea they were that easy to bypass on a social level.

Also this CC# generator falls outside of the 2FA scope, also something I asked them about several years ago and received the same reply "it's not our service".

It's scary.

>You can bypasss this by calling them - they only ask for 1 thing to authenticate you.

The domain for my personal site is shared with my family. My father registered the domain and all of the details in the account use his information. I had just created an AWS account and wanted to move the site's DNS to Route53.

I was able to call into the domain registrar and get exactly zero of the details correct, but they pointed the domain to Route53. It was hilarious how bad it was. I used my social, my name, my address, etc., none of which matched the info on file.

Even if I had used my father's info, it (except the social) would have been wrong because we lived overseas on a military base. When your system says Japan and someone from the US is calling, that should set off all sorts of alarm bells.

Swedish social security numbers are public information btw, just to clarify the insanity - I can call in to the government register and ask for anyone's number, there isn't even any obfuscation or semi-privacy about it like US SSNs.

there isn't even any obfuscation or semi-privacy about it like US SSNs.

GOOD. The US "private" SSN system is completely messed up. You can't commit identity theft by just knowing a personnummer. Very, very much unlike the US...

But you can. People treat the full "personal numbers" as a secret and if you can recite one, nobody will think you're anyone different. It's not meant to be this way, but in my experience it is.

The Swedish personal numbers are not a secret, so that is not a protection in any kind. You can get the number for anyone by asking the tax agency.

reminds me of this story http://www.windytan.com/2015/04/trackers-and-bank-accounts.h...

If you also can choose your account name, use it as sort-of additional password space.

I have accounts with several instances where I could give you my password without running much risk of you logging in; even if their phone support would give out my account name, chances are they or you would misspell the line noise that it looks like.

Yes, Schwab does let you choose your account name. I'm not sure how many chars it can have.

8 characters max

Ha. Even better, they're also CASE INSENSITIVE!!!

We discussed this here a year ago: https://news.ycombinator.com/item?id=8783790

*Handled

They now support 200+ character passwords.

They fixed that recently. Change your password

My bank (German "Sparkasse") only allows passwords with exactly 5 letters or numbers for their online banking. I asked why they're doing this, but didn't get a good response.

When I asked, I got the answer that I could chose an arbitrary 16 character long user name, that the password may contain special characters, that the number of allowed failures for logging in is limited and that any actual money transfers are protected by a TAN. So it may not be that bad, given that the PIN for my EC card has only four numbers.

Still, I agree that this scheme is somewhat odd and no limitation on the password length would be preferable.

One of my neighbors when I was growing up worked in the FBI's cybercrime division. His wife always complained about how he never let her do any of their banking or serious financial transactions online. When I hear stuff like this, I get why.

That used to be true, but Schwab has since removed their character limit. I just updated my password to one having more than sixty characters.

Which makes you think - Schwab is keeping probably billions of dollars safe. I've never heard of a theft from them, including via online account compromise. Meanwhile, many other sites doing better jobs of following security best practices can't keep even email addresses secure.

Maybe we're the ones doing it wrong, and it's us that should be learning from them?

Would love it if there were some kind of markup standard that password managers could read to determine the site's password rules when generating strong passwords.

I have the problem now with sites that don't tell you their password policy - I'll try several times to generate a password in LastPass and then end up with several entries for the same site, which I now need to inspect to determine which one is the one I don't want to delete. Hugely annoying.

I would love it if there were FCC-mandated password handling standards, like a (long) minimum max length, a (wide) mimimum permissible charset, and forbidden plaintext storage. It's arguably an issue of national security.

(Or some other appropriate regulatory agency).

Jurisdiction over which agency gets to do "cyber" stuff has been an open question for the last thirty years. You can make good arguments that it should be covered by the FBI, NSA, DHS, ATF, the secret service, etc etc.

(Yes, the Secret Service! The famous raid on Steve Jackson Games back in 1990 was actually carried out by Secret Service agents, who thought that GURPS Cyberpunk was an actual hacking manual.)

There sort of is. In HTML5, text-based form elements have a new "pattern" attribute which takes a regular expression that matches valid input, so the browser can do client-side validation without using JavaScript to intercept the form before it's posted and such. Assuming the site developers have bothered to implement it on their site, then theoretically a password manager could use that to determine valid characters for generated passwords (or, at least, invalid ones). I don't know if any of them actually do this, though.

http://www.w3.org/wiki/HTML/Elements/input/password

The thing is, how many sites are going to have developers clued-up enough to incorporate this markup, but not clued-up enough to avoid stupid password policies that break password managers?

We only run into trouble because sites incorporate silly requirements like "you must have at least one symbol, even if your password is 48 characters long." Fixing that really seems like the better and more attainable goal.

Solaris, an otherwise good quality enterprise operating system, had an 8-character limit just like that for decades. They only fixed it in the default configuration maybe five years ago. You can read about it here: http://blog.mc-thias.org/?title=solaris-10-password-length-l...

Reply on news.ycombinator.com