Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Many sites won't accept my passwords (SHA1_Pass). They say that they are too long or have inappropriate chars or that they are not complex enough. Here's an example of inappropriate chars:

UTP+NnhabgHKx6

So I make a different password and the sites say it is too weak as it has no special chars or uppercase chars:

5133fe36785a6e01cac7a68c9c111afff5bb4821

So I give up and type Password1 which is normally accepted.



Whenever I come across a site that refuses to let me sign up with a secure password, I either leave right away or send them a short mail first.

There were times where I had to rely on password managers too, though. Banking sites are one common place ...


>Banking sites are one common place ...

I can't tell you the number of times I've tried to explain to banks that 'security questions' are absolutely worthless, and that their 'secure password' policy is actually worse than no policy at all.

One bank actually requires passwords to be between 6 and 8 characters in length, with at least one letter and one number and no special characters.


Yep. In my experience, banking and financial websites have much worse password policies than the web at large. E.g., fidelity.com has a maximum password length of 12 characters. USAA has a maximum password length of 12 characters.

What the fuck.


This is exactly what my bank requires. Worst part after I told them that this is irresponsible: A few years ago they only allowed a 5-digit PIN for their web login.


Mine used to beat yours by one, as the code was by default the actual PIN of my credit card, while the username itself was 6 digits. It's so... vile I can't even begin to describe it.


That's okay as long as the account is inactivated after 3 failed login attempts. Which is, of course, only sensible for banks which have local branches where you can re-activate your account.

For a pure online bank this would be irresponsible, indeed.


It's not even okay then. If I know that the universe of possible passwords is so small, it's possible to use that to allow me to crack the encryption much more easily (for example).


My biggest pet peeve is how no one explains their password constraints until you break one of them.


I recently did a password change for some Apple site (iTunes, I think) and they handled this nicely. They put up a box beside the password field that listed the requirements, and as soon as I started typing it started dynamically changing the list to mark the requirements that my current entry did not meet.


I just went through the iTunes "forgot my password" process and had a different experience. According to that box to the side, my new password passed all their requirements, yet on submit it kept rejecting it. I finally got it to accept a password when I stopped trying to use spaces. Are there other characters their back end rejects that the front end allows?


Apple's entirely inconsistent in this: IIRC I've been able to set simple passwords if I reset my Apple ID password through a certain page, but am forced to use a complex password if I reset it through a different page. (Such as id.apple.com vs. store.apple.com vs. developer.apple.com) I can't remember which is which, but I remember coming to this realization multiple times.


Blizzard please? 13-20 characters, an upper case character, a lower case character, a number and a symbol. I'm not using LastPass here, because battle.net requires me to type that every damn time I start Starcraft.


My solution so far is:

  cat /dev/urandom|base64|tr -d '/+'|head -c10
Nearly every site supports a-z,A-Z,0-9 at 10 characters


10-character apha-numeric password is crackable in a matter of days: http://whitepixel.zorinaq.com/


> 10-character apha-numeric password is crackable in a matter of days: http://whitepixel.zorinaq.com/

I think the assumption here is that the password isn't an MD5 hash, but instead something a little more resilient. If it's MD5, you're probably screwed anyway.


Does that break more then md5? I thought it was well known that md5 was a bad password hash algorithm.


I don't know why an application couldn't also attack other hashing algorithms. It's just about brute force creating lots of hashes.

This app also uses GPUs to brute force TrueCrypt: http://www.golubev.com/igprs/


Because algorithms like bcrypt have a computational difficulty parameter. You can dial it up so that every check takes something ridiculous. Now instead of brute forcing all of those possibilities in 10 days, it's 1000 centuries.


Hash functions are designed to be fast, to use them in stuff like hash tables, hash structures, checksums etc when the faster the function the better (as long as it doesn't have too many collisions). If you transfer data fast and need a lot of checksums or if you do operations on hash structures your goal is speed. On the other hand with passwords you don't want hash, you want encryption and preferably encryption which is very difficult to calculate as encrypting passwords is rare operation and could take those extra CPU cycles for normal use but which is crucial to make it difficult to crack by brute force.

See: http://en.wikipedia.org/wiki/Cryptographic_hash_function

Using hash instead of encryption for passwords is major security mistake


Have you used pwgen before?


apg is another good one, and if you call it with no arguments, it defaults to 'complex passwords with memorable syllables' (eg "zuWeebsIbep3 (zu-Weebs-Ib-ep-THREE)").


I recommend PwdHash [https://www.pwdhash.com/]. It has extensions for Chrome, Firefox, and Opera, and I have not yet had a site complain about its generated passwords.

zxcvbn assigned my generated password for their site a crack time of ~21 million years.


Similar to PasswordMaker I guess?

http://passwordmaker.org/

It offers lots of nice-to-have options.


Same is true for diceware passwords, because they are in a dictionary.

http://world.std.com/~reinhold/diceware.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: