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

Stop forcing arbitrary password rules

ryanwinchester.ca

Post reply on HN
Print view View original

11–20 of 196 posts

Re: Stop forcing arbitrary password rules

#11

Post by lifeisstillgood »

I use pwsafe for iOS (yes trusting some guy built a binary ok) to keep my many passwords for each domain. It will generate (no I don't know the RNG) passwords based on policy settings (length, characters, etc)

And like the author, flat out my number one bugbear is that no matter what random(ish) password I choose before signing up, some idiot will decide that my 12 letter password is too long or my password must have an upper case, or a number of a special character - but never in a consistent manner.

I really want to just move to google authenticator and one factor auth. Just stick a QR code up, let me photo it on screen and I will give you a HMAC code right back.

No passwords. Just illusion

Re: Stop forcing arbitrary password rules

#12

Post by DanBC »

ErrantX wrote: post #4

Argh! The XKCD entropy comic. Back away slowly.. The "4 common words" password meme was around a lot after that comic. However, such passwords are definitely not secure because a good dictionary attack will break it in hours. You do not have as much entropy as you think with them. The same problem tangentially applies to his suggested password schema to. The problem is: as soon as you start using human word or pseudo…

What do you mean when you say "dictionary attack", because I think you're talking about something to me.

Re: Stop forcing arbitrary password rules

#13

Post by mrb »

forgotpwtomain wrote: post #3

I agree with the point the author is making and generally am just as annoyed by arbitrary password rules; nevertheless: > chili dog monkey nutso Is definitely not 18 quintillion years at best it's approximately 250000^4 which is 2^72. A good (though still requiring some memorizing effort approach) would be something along the lines of https://github.com/bitcoin/bips/blob/master/bip-0039.mediawi... which uses a standa…

It calculates 18 quintillion years because howsecureismypassword.net is simplistic and doesn't realize english words are being used. It categorizes each character into some categories (see https://howsecureismypassword.net/assets/js/app.min.js):

  // Standard ASCII Characters
  add('ASCII Lowercase', /[a-z]/, 26);
  add('ASCII Uppercase', /[A-Z]/, 26);
  add('ASCII Numbers', /\d/, 10);
  add('ASCII Top Row Symbols', /[!@£#\$%\^&\*\(\)\-_=\+]/, 15);
  add('ASCII Other Symbols', /[\?\/\.>\,
It sees the password is 22 characters long, and contains a-z chars (lowercase) and a space char (other symbols) so it estimates each char is drawn from a set of 26+19 = 45 letters. And it assumes the default bruteforcing speed is 4 billion passwords per second. So:

  45**22/4e9/3600/24/365.25 = ~18 quintillion years.

Re: Stop forcing arbitrary password rules

#14

Post by leni536 »

ErrantX wrote: post #4

Argh! The XKCD entropy comic. Back away slowly.. The "4 common words" password meme was around a lot after that comic. However, such passwords are definitely not secure because a good dictionary attack will break it in hours. You do not have as much entropy as you think with them. The same problem tangentially applies to his suggested password schema to. The problem is: as soon as you start using human word or pseudo…

The XKCD entropy comic assumes dictionary attack. This is why he only counts 11 bits of entropy (2048 variations) for each word.

Re: Stop forcing arbitrary password rules

#16

Post by plorg »

I was in Chicago with my family recently and purchased a one-day pass for the CTA. When I returned home I found you could create an online account connected to the card, ostensibly to be able to fill it up automatically, but also to track your ridership. I thought it would be interesting to see what kind of data a rider could get from the card.

I spent quite a bit of time trying to create an account only to receive a generic 50x error page each time. I tried disabling adblockers, completely unblocking javascript, disabling extensions, and nothing worked. I tried it in different browsers, and on different computers. I still received the 50x error. Then, on a whim, I tried using a different password. When that worked, I tried changing the password using 1-character-removed tweaks of the original. There was a single character that, it turns out, would cause the application to choke on passwords (I don't remember which character). Presumably it was an escape character or a semicolon.

It's not impossible for account systems to fail in unexpected ways, so there are probably more than a few (poorly-designed) websites which have seemingly arbitrary password requirements which are designed to avoid the kind of error I found above. Still, it would be better to fix the error in the webapp than to try to patch it by limiting the user input - that's an obvious security problem waiting to happen.

Re: Stop forcing arbitrary password rules

#17

Post by scintill76 »

emsy wrote: post #15

Second worst password rule: preventing to paste in the password field. As seen at The OS X FileVault dialog, PayPal, Blizzard and many more....

Chrome hackaround:

1. Right-click the field, Inspect element.

2. Go to Console tab, type: $0.value = 'mypassword';

$0 is the last selected element: https://developer.chrome.com/devtools/docs/commandline-api

Re: Stop forcing arbitrary password rules

#18

Post by [deleted] »

plorg wrote: post #16

I was in Chicago with my family recently and purchased a one-day pass for the CTA. When I returned home I found you could create an online account connected to the card, ostensibly to be able to fill it up automatically, but also to track your ridership. I thought it would be interesting to see what kind of data a rider could get from the card. I spent quite a bit of time trying to create an account only to receive a…

[deleted]

Re: Stop forcing arbitrary password rules

#19

Post by throwaway125 »

emsy wrote: post #15

Second worst password rule: preventing to paste in the password field. As seen at The OS X FileVault dialog, PayPal, Blizzard and many more....

Most of the time you can paste the password in another field (like the username) and select and drag it to the password field.

Browsers should probably not allow that kind of interaction between javascript and the password field.

Post reply on HN