Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sites with dumb password rules

github.com

Post reply on HN
Print view View original

201–210 of 327 posts

Re: Sites with dumb password rules

#201

Post by pvorb »

usr1106 wrote: post #160

Many complaints are that non-ASCII characters (which all but one European languages have natively) are not allowed. While I agree that allowing them would be good for password security past experience has made me paranoid. Not all systems handle non-ASCII the same way, so when you change browsers or they upgrade their system your password might no longer work. Today Unicode is used a lot so it gets better, but it's s…

Another case where I tend to use the plain English alphabet for passwords/passphrases is with disk encryption. I have a German keyboard, but before Linux is up and running, I'm never sure whether the system assumes an English or German keyboard layout. And since I can't see which characters I type, the safe bet is to only use the plain alphabet and make the phrase a little longer.

Re: Sites with dumb password rules

#202

Post by Tepix »

United MileagePlus:

They ONLY offer multiple choice questions for the security questions!

Of course, for some questions none of the answers are correct (favourite artist etc). On the other hand it would be dumb to choose a correct answer that someone else could find out and then take over your account.

Some of the questions have as few as 12 valid answers - e.g. "in which month...". Also in the select box where you pick your answer the months are sorted in a nonsensical order.

I ended up picking questions with more possible answers and choosing a random answer and putting it into my password safe.

Infuriating!

Re: Sites with dumb password rules

#203

Post by meuk »

blackoil wrote: post #170
meuk wrote: post #168

I understand that you follow some misguided security guidelines that state that a password must contain special characters and have a length of at least X. What I don't understand is why sites use a maximum password length. They shouldn't save your password anyway, and only compare the hash, right?

Cost of calculating 10k character hash? IMO above 30 length serves no practical purpose.

To put this in perspective: The cost of calculating a 10k character hash is negligible compared to serving a modestly sized image.

Still, you have a point that allowing arbitrary sized passwords to denial-of-service attacks. Still, a more reasonable limit would be 100 or 256, for example.

Re: Sites with dumb password rules

#204

Post by pvorb »

julianwachholz wrote: post #180
transreal wrote: post #153

I've been getting pretty annoyed by the "Security Questions" some sites have you setup. A client I work with gave me a vendor account, with a preset list of security questions I had to answer. One was 'What was the color of your first car?'. I typed in 'Red', and got an error that the entry needed to be at least 4 characters long.

The name of my childhood pet was "FVrE9msW9DLBAx". Makes for fun conversations on the phone.

Mine was "78 nails and 7 Greek philosophers", which works a little better on the phone. ;-)

Re: Sites with dumb password rules

#205

Post by d33 »

I like the idea of such "shame list". The question is though, how would you prioritize and incentivize those websites to change?

My quick idea is that it would be good to have a way of reproducing those cases somehow; not sure how though, because registration is something that is difficult to automate, so we'd probably need some browser extension to do this research. Once we could automatically test (or semi-automatically, waiting for a user to verify) whether this is still an issue, we could create a website where one could sort by most popular / annoying / old flaws, maybe also arranged by communities so that changes would happen.

Either way, I appreciate kicking this off. It's definitely a good start. I just wish we could transition from this to actually changing this deliberately, as opposed to just shaming and hoping for organizations to eventually fix their things.

Re: Sites with dumb password rules

#206

Post by tialaramex »

medmunds wrote: post #85

For a nice counterexample, check out login.gov, the unified authentication service that seems to be replacing individual approaches at many US government sites. Their password requirements: “It must be at least 12 characters long and not be a commonly used password. That’s it!” [1] Oh, and login.gov allows pasting from a password manager. [1]: https://login.gov/help/creating-an-account/how-to-create-an-...

Ooh, also FIDO keys. Nice. This is 100% the best option listed (possibly not for actual US government employees, your employer issued token might arguably be better) because FIDO is strongly incompetence resistant, and when combined with the use of login.gov over each site having a separate login that's a huge security win.

- FIDO keys don't have identity. Each FIDO key is different of course, mine can't be used in place of yours. But an activist can use the same key for their Facebook "Smash Exxon" page where they are never shown without mask and also for their login.gov ID where they sort out government affairs using their true full name and address, yet even if the government and Facebook and Exxon all work together they can't tell those are the same person from the credentials.

- FIDO keys don't move secrets. There is usually a "secret" random value baked inside your key to make it unique, but everything sent back and forth is public, so if it leaks that's no big deal. login.gov could literally paint all the FIDO credentials it has on the side of the Capitol building for everybody to see and it would make no difference to security.

Re: Sites with dumb password rules

#207

Post by screenbeard »

bscphil wrote: post #88
rolltiide wrote: post #82

Earlier quoted context omitted.

Hi, this needs a checklist or ability to see severity of infractions because some of these edge cases are very dumb to elevate alongside the truly broken flows

Yeah, compare the very first two on there right now. The first is "can't use '%'". The next one has 7 very specific rules.

That one smacks of character encoding issues or badly sanitised inputs.

Re: Sites with dumb password rules

#208

Post by joshuaissac »

julianwachholz wrote: post #180
transreal wrote: post #153

I've been getting pretty annoyed by the "Security Questions" some sites have you setup. A client I work with gave me a vendor account, with a preset list of security questions I had to answer. One was 'What was the color of your first car?'. I typed in 'Red', and got an error that the entry needed to be at least 4 characters long.

The name of my childhood pet was "FVrE9msW9DLBAx". Makes for fun conversations on the phone.

It is better to pick names with actual words. An attacker can otherwise say that the answer is just a bunch of random characters, and there is a risk that a naïve customer support representative may accept it.

Re: Sites with dumb password rules

#209

Post by screenbeard »

nolok wrote: post #148

Most of these are dumb rules, but a few really makes you feel like something smelly is going on in the underlying code. Like the first one that specifically restrict %, my head started screaming “sql injection somewhere”

Or just an inability to deal with character encoding.

Re: Sites with dumb password rules

#210

Post by y4mi »

lbeltrame wrote: post #196
jdelman wrote: post #47

My favorite dumb password experience involves EZPass, a system for paying tolls without cash, in New York. I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figu…

Mine is my workplace. They mandate changing the password every 3 months (so most people use post-its) and their password change utility accepts special characters for input but mingles them when actually stores them (the backend uses AD for authentication, but the password change goes through a custom web form). And of course then logging in doesn't work at all. It took me days to figure out what was going on. I have…

Just use an ultra secure password schema such as September2019@$ . They obviously want you to use it considering that policy
Post reply on HN