• Kasper (unregistered) in reply to Anon
    Anon:
    Except those restrictions actually reduce security
    Not always. In some cases password security would be so bad without the restrictions, that it could not get any worse.

    For example if users with read-write access to the most sensitive data in your system would choose a password with only four characters (if you would let them), then enforcing a minimum length cannot reduce security. That does not mean it is guaranteed to help, but it does not hurt.

    I propose that moving forward any password policy satisfying the following criteria be officially known as lame.

    Let m be the maximum length of passwords. Let r be the total number of alphanumeric strings of length m or less, which are rejected by the policy.

    Then if r > 3^m, the password policy is lame.

  • (cs) in reply to Mason Wheeler
    Mason Wheeler:
    rootkit:
    TRWTF is storing a password in PLAIN FUCKING TEXT instead of a hashed value like SHA1(salt(password))

    This, this, a thousand times this. It should not matter if your password is 14 characters or 400, because they should all hash to a uniform-length string.

    CHAP requires that both sides know the plaintext password.

  • (cs)

    In 1998, a friend of mine had a laptop at high-school. Knowing his friends like to play pranks, he used the BIOS settings to require a password on boot. He typed in his 9-character password and saved it to the BIOS.

    The computer restarted and asked for his password. He typed the same 9-character password. Rejected. Okay, was there a capital letter? Rejected. Did I make a typo? Rejected. Rejected. Rejected.

    Finally he caved, realising he must have made a completely random error in his password that would be near impossible to find. He called up tech support expecting to have to send his laptop in to have the BIOS reflashed. When he explained the situation, they immediately fixed the problem for him, over the phone.

    "The password can only be 7 characters long."

  • (cs)

    My mother worked at a bank in the late 80s when banks still had monochrome green terminals.

    She set up her password for her login. She quickly typed 6 characters and hit ENTER. Nothing happened, so she hit ENTER again and the password was accepted. And every time she entered her password she would have to hit ENTER twice for the password to be accepted.

    It turned out that passwords were 7 characters fixed length. Her password included a CR as the last character.

  • Sam (unregistered)

    Unfortunately EA's Origin is pretty much the same, except 16 characters. Makes me scared to use the service...

  • aoweo (unregistered) in reply to Algorythmics
    Algorythmics:
    faoileag:
    DumbByAssociation:
    Personally, I always view policies concerning the number of characters in a password, or permissible characters, as a first rate demonstration that the organisation doesn't know what its doing - and then take my business elsewhere...
    It seems to be a common misapprehension that taking possibilities that look "obvious" to a human away from a given set of data enhances security.

    As far as I know the germans started it in WWII - certain wheel settings where not allowed for their enigma machines, because they were considered too obvious. British military intelligence on the other hand knew about those restrictions, thus enabling Turing to crack the communication faster since he could skip combinations he knew not to be allowed.

    And I think I have read somewhere that the same is practiced on ATM pins - you will not get a generated pin like "0000" or "1234".

    So, yeah, let them declare "passwords must at least be 8 characters long". Then any interested hacker can save the cycles to create hashes for character combinations with a length of less than 8 characters.

    the data set for 8 characters is large enough that those who used 8 character passwords already are not massively (although it's true they are slightly) less safe, while those who would use fewer characters are significantly safer as a result.

    the average security of your users is higher as a result of the restrictions, and as a company, the average is all you probably care about

    https://howsecureismypassword.net/

    http://www.passwordmeter.com/

    although seriously, the password you use depends on the application.... Let's keep in mind that lockout after X attempts makes brute force vcery difficult (if you're absolutely certain that someone logs on in a certain interval successfully, you could try X-1 combinations in that interval, but it's slow and likely to cause them to lock themselves out which might have them reset their password). If you're worried about people using rainbow tables and the like, they'd have to had access to them in the first place - which would mean a breach somewhere - which is not always likely - and the likelihood of this happeneing depends on the use (and you'd hope the most critical places where you use a password it would be well salted and hashed).

    For example, I tend to use a more obscure password for my bank (which has extra factors of identification anyway) than for my email account. My work passwords tend to be less obscure again, because our systems aren't available to the outside world - so I simply have to deter my colleagues....etc.....

    That said, I would probably avoid anything appearing in a list of "10 most common passwords" (and probably even 100)....

  • hot dog (unregistered) in reply to foo AKA fooo
    foo AKA fooo:
    faoileag:
    It seems to be a common misapprehension that taking possibilities that look "obvious" to a human away from a given set of data enhances security.

    As far as I know the germans started it in WWII - certain wheel settings where not allowed for their enigma machines, because they were considered too obvious. British military intelligence on the other hand knew about those restrictions, thus enabling Turing to crack the communication faster since he could skip combinations he knew not to be allowed.

    More precisely, the enigma would never encrypt a character to itself, thereby reducing the number of possible results from 26 to 25 and allowing them to exclude words, e.g. EET could not be encypted from DER, EIN or MIT (3 common German words).
    I thought they realised this pretty early on, and one of the changes they made was to allow mapping back to itself (I think via the plugboard?)

  • hot dog (unregistered) in reply to rootkit
    rootkit:
    TRWTF is storing a password in PLAIN FUCKING TEXT instead of a hashed value like SHA1(salt(password))
    and more than one shake of salt.....
  • George (unregistered) in reply to Anon
    Anon:
    faoileag:
    DumbByAssociation:
    Personally, I always view policies concerning the number of characters in a password, or permissible characters, as a first rate demonstration that the organisation doesn't know what its doing - and then take my business elsewhere...
    It seems to be a common misapprehension that taking possibilities that look "obvious" to a human away from a given set of data enhances security.

    As far as I know the germans started it in WWII - certain wheel settings where not allowed for their enigma machines, because they were considered too obvious. British military intelligence on the other hand knew about those restrictions, thus enabling Turing to crack the communication faster since he could skip combinations he knew not to be allowed.

    And I think I have read somewhere that the same is practiced on ATM pins - you will not get a generated pin like "0000" or "1234".

    So, yeah, let them declare "passwords must at least be 8 characters long". Then any interested hacker can save the cycles to create hashes for character combinations with a length of less than 8 characters.

    I'll do you one further on PINs:

    The obvious, 0000/1111/2222/etc. and 1234, aren't allowed.

    At many banks, there are additional restrictions:

    a) No sequential digits (1238 is right out, as are 7589, 0235) b) No REVERSE-sequential digits (2138, 0325) c) No repeating digits (0225, 1883)

    At some banks, ALL of these restrictions are in place, which means cracking a PIN can become trivial (as though the space wasn't small enough by itself!).

    A lot of our banks have moved to 6 digit pins....but of course that means everyone uses dates now (and I don't think we have the restrictions from a,b or c above)

  • NotZeus (unregistered) in reply to chubertdev
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.

    It's almost like he was being sarcastic!

    Ok, so you do know the N in "PIN" means "number", right?

  • pedant (unregistered) in reply to Geraden
    Geraden:
    No passwords should not be encrypted. They should be hashed.

    Encryption is when you take some input, and a key, and you create a new output that is related to the input by that key.

    If hackers break in to your system and can see your software, they can see the key you are using, since you must keep that key on hand for whenever you want to decrypt the password to do a check.

    Hashing is an algorithm that takes an input and generates an output. Hashing algorithms are designed with advanced mathmatics to be extraordinarily hard to go in reverse. So HASHING a password is easy, but DEHASHING is assumed to be impossible.

    A modern challenge-response password check scheme would use hashing. Assuming the user has already created an account and wants to log in, he visits the log in page. When he visits the page, he types in his password. His password never leaves his computer.

    Instead, his client (usually a browser in the case of websites) takes his password, hashes it, then uses it as a key to encrypt a randomly generated challenge string from the server. His client sends that encrypted string, and NOT his password, to the server. Since the challenge string is random each time, the response should be different each time to. And your password is never transmitted. The server will compare your response to what it thinks the right answer is (it will encrypt the challenge string with your password hash to know what to expect) and provide authentication or access denied behaviour.

    Basically, encryption is to protect data by using a password. Hashes are to protect passwords themselves. But both are generally used together in certain challenge-response models.

    Hashes are 1 to many, so to reliably reverse engineer a hash is impossible (you cannot be certain your result is the original string). Of course, the string will still hash to the right result so it doesn't really matter...unless it's salted. This is why we need salt people. It's not just that Hash tastes bland without it. Something nicely salted makes it very, very, very difficult to reverse enginner - and if done well means that a hacker can't try to force passwords en-masse....

  • milas (unregistered) in reply to NotZeus
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY you
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.

    It's almost like he was being sarcastic!

    Ok, so you do know the N in "PIN" means "number", right?

    Can anyone play this game, or do youneed to be a certain height?

  • (cs) in reply to milas
    milas:
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY you
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.

    It's almost like he was being sarcastic!

    Ok, so you do know the N in "PIN" means "number", right?

    Can anyone play this game, or do youneed to be a certain height?

    I honestly expected to hear a "WHOOSH" when reading that comment.

  • John (unregistered) in reply to faoileag
    So, yeah, let them declare "passwords must at least be 8 characters long". Then any interested hacker can save the cycles to create hashes for character combinations with a length of less than 8 characters.

    The reality is though minimum password lengths and hell even divulging the length of your password does not materially weaken the security. If I tell you my password is 14 characters long, yes you save some time not having to computer hashes for lengths 1-13, but the number of hashes you will need to brute the entire 14 char keyspace is bigger than 1-13 combined anyway.

  • Me? I'm no one (unregistered)

    As usual, TRWTF is the commentators, especially ones who think that hashing a password with any form of SHA is a Good Idea™.

    Go learn you some education: http://codahale.com/how-to-safely-store-a-password/

    (I had this with nice URL linking and everything, but Askimet in it's great wisdom decided it didn't like it)

  • Anon (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Anon:
    I'll do you one further on PINs:

    The obvious, 0000/1111/2222/etc. and 1234, aren't allowed.

    At many banks, there are additional restrictions:

    a) No sequential digits (1238 is right out, as are 7589, 0235) b) No REVERSE-sequential digits (2138, 0325) c) No repeating digits (0225, 1883)

    At some banks, ALL of these restrictions are in place, which means cracking a PIN can become trivial (as though the space wasn't small enough by itself!).

    You can trivially show that this reduces the number space by a factor (crudely) of (7.0/10)**3 == 0.343, thus eliminating two-thirds of the number space...

    (The combinatorics are more complex than that, of course, unless they feel like eliminating 90 as being consecutive digits. Note that the all-same combinations are barred by case (c), while combinations like 1234 or 4321 are eliminated respectively by (a) and (b). The abc rules don't block 2468, 3141 and other patterny combinations.)

    Never trust someone to properly block 11 and -also- properly block 111*, *111, and 1111.

  • Anone (unregistered) in reply to Anon
    Anon:
    Never trust someone to properly block *11* and -also- properly block 111*, *111, and 1111.

    If they haven't blocked 111*, *111, or 1111, how can they have properly blocked 11?

  • Russell (unregistered) in reply to Dee

    No, you have to binary search it; 12 6 9 8

  • QJo (unregistered) in reply to NotZeus
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.

    It's almost like he was being sarcastic!

    Ok, so you do know the N in "PIN" means "number", right?

    I thought everybody knew these TLA abbreviations.

  • (cs) in reply to QJo
    QJo:
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.

    It's almost like he was being sarcastic!

    Ok, so you do know the N in "PIN" means "number", right?

    I thought everybody knew these TLA abbreviations.

    Remembering all of them is a PITA arse.

  • Norman Diamond (unregistered) in reply to DumbByAssociation
    DumbByAssociation:
    Personally, I always view policies concerning the number of characters in a password, or permissible characters, as a first rate demonstration that the organisation doesn't know what its doing - and then take my business elsewhere...
    If an organization doesn't allow ¶єニç as a password, you take your business elsewhere?
  • Norman Diamond (unregistered) in reply to Anon
    Anon:
    Beyond a certain point, password restrictions and expirations just cause users to start writing down passwords on post-it notes at their desks.
    That actually isn't a problem MOST of the time. A cyberspace hacker will not get your password from that post-it note. Though a meatspace burglar will.
  • Norman Diamond (unregistered) in reply to Lucent
    Lucent:
    What else could "same" mean?
    "skimmer access made easy"
  • (cs) in reply to Norman Diamond
    Norman Diamond:
    Anon:
    Beyond a certain point, password restrictions and expirations just cause users to start writing down passwords on post-it notes at their desks.
    That actually isn't a problem MOST of the time. A cyberspace hacker will not get your password from that post-it note. Though a meatspace burglar will.

    That's one of those weird situations they've done studies on, and have proven that the only users that will take any steps to make sure the written passwords are protected to a sane degree are the ones who would already be secure with their password to begin with.

  • Windows NT (unregistered) in reply to John
    John:
    If I tell you my password is 14 characters long, yes you save some time not having to computer hashes for lengths 1-13, but the number of hashes you will need to brute the entire 14 char keyspace is bigger than 1-13 combined anyway.
    Wanna bet?
  • foo AKA fooo (unregistered) in reply to chubertdev
    chubertdev:
    QJo:
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.
    It's almost like he was being sarcastic!
    Ok, so you do know the N in "PIN" means "number", right?
    I thought everybody knew these TLA abbreviations.

    Remembering all of them is a PITA arse.

    Please stop this abuse of RAS Syndrome misuse and turn off your LCD displays.

    Foo O. Fooo, CEO Officer, Department of Redundancy Department

  • Norman Diamond (unregistered) in reply to chubertdev
    chubertdev:
    milas:
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY you
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.
    It's almost like he was being sarcastic!
    Ok, so you do know the N in "PIN" means "number", right?
    Can anyone play this game, or do youneed to be a certain height?
    I honestly expected to hear a "WHOOSH" when reading that comment.
    What you heard was the PIN. The automatic teller automatically told the PIN to every machine on the [t]arget network.
  • Meep (unregistered) in reply to Anon
    Anon:
    Except those restrictions actually reduce security -- each additional restriction results in a less-computationally-complex password than the user would likely have chosen by themselves.

    They only result in a weaker password than a random password generator would have chosen.

    People pick memorable passwords, and the set of memorable symbols is small. By forcing people to add additional sets of symbols, you increase the overall complexity of the password.

    Beyond a certain point, password restrictions and expirations just cause users to start writing down passwords on post-it notes at their desks.

    Why not write them down? If someone can break into your office, they can install a keylogger on the system anyway.

  • (cs) in reply to Geraden
    Geraden:
    Instead, his client (usually a browser in the case of websites) takes his password, hashes it, then uses it as a key to encrypt a randomly generated challenge string from the server. His client sends that encrypted string, and NOT his password, to the server. Since the challenge string is random each time, the response should be different each time to. And your password is never transmitted. The server will compare your response to what it thinks the right answer is (it will encrypt the challenge string with your password hash to know what to expect) and provide authentication or access denied behaviour.
    Congratulations, your password is now just your password hash.

    All that fancy secret stuff you remember? That is just something you give to your browser to allow it to calculate your "real" password.

    An attacker doesn't need to know the fancy secret stuff to log in as you. They only need the hash. Sure, they can't use the hash to figure out the fancy secret stuff, but they don't need that. When the server sends them the challenge, they use the hash to calculate the response, and send that back. So the hash is your real password, and your fancy secret stuff is just the easy password you give your computer to have it figure out your real password.

    Oh, and it gets worse, now: your real password (the hash of the fancy stuff you're remembering) is stored in the clear on the server. No salting, no hashing, nothing. If I can see the stored hash, I can log in as you.

    Congratulations, you've just learned the first rule of crypto: don't roll your own crypto. Even if you think you know what you're doing, you're probably wrong.

  • Superboy (unregistered) in reply to random_garbage
    random_garbage:
    Congratulations, you've just learned the first rule of crypto: don't roll your own crypto. Even if you think you know what you're doing, you're probably wrong.
    Crypto rolls when I tell him to. He shakes hands when I tell him to too.
  • Le Avocat Diabolo (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Anon:
    Beyond a certain point, password restrictions and expirations just cause users to start writing down passwords on post-it notes at their desks.
    That actually isn't a problem MOST of the time. A cyberspace hacker will not get your password from that post-it note. Though a meatspace burglar will.
    I am more worried about the clowns at my work logging onto my computer than some script kiddie. Post it notes are evil...EVIL I tell you....

    and I've locked up the T-bones so the meatspace burglar can't get them.

  • Chris (unregistered)

    Many, many websites and services truncate passwords when you set them but do not truncate them when you try to use them. On the same system. Made by the same people. It's gotten to the point where I've encountered this often enough that if my password fails after two attempts I just start clipping characters off the end until it works.

  • Ms Corby (unregistered)

    I'm starting to think a lot of people are going around with boogie board bags full of hash......

  • BeenThereDoneThat (unregistered) in reply to aoweo
    aoweo:
    Algorythmics:
    faoileag:
    DumbByAssociation:
    Personally, I always view policies concerning the number of characters in a password, or permissible characters, as a first rate demonstration that the organisation doesn't know what its doing - and then take my business elsewhere...
    It seems to be a common misapprehension that taking possibilities that look "obvious" to a human away from a given set of data enhances security.

    As far as I know the germans started it in WWII - certain wheel settings where not allowed for their enigma machines, because they were considered too obvious. British military intelligence on the other hand knew about those restrictions, thus enabling Turing to crack the communication faster since he could skip combinations he knew not to be allowed.

    And I think I have read somewhere that the same is practiced on ATM pins - you will not get a generated pin like "0000" or "1234".

    So, yeah, let them declare "passwords must at least be 8 characters long". Then any interested hacker can save the cycles to create hashes for character combinations with a length of less than 8 characters.

    the data set for 8 characters is large enough that those who used 8 character passwords already are not massively (although it's true they are slightly) less safe, while those who would use fewer characters are significantly safer as a result.

    the average security of your users is higher as a result of the restrictions, and as a company, the average is all you probably care about

    https://howsecureismypassword.net/

    http://www.passwordmeter.com/

    although seriously, the password you use depends on the application.... Let's keep in mind that lockout after X attempts makes brute force vcery difficult (if you're absolutely certain that someone logs on in a certain interval successfully, you could try X-1 combinations in that interval, but it's slow and likely to cause them to lock themselves out which might have them reset their password). If you're worried about people using rainbow tables and the like, they'd have to had access to them in the first place - which would mean a breach somewhere - which is not always likely - and the likelihood of this happeneing depends on the use (and you'd hope the most critical places where you use a password it would be well salted and hashed).

    For example, I tend to use a more obscure password for my bank (which has extra factors of identification anyway) than for my email account. My work passwords tend to be less obscure again, because our systems aren't available to the outside world - so I simply have to deter my colleagues....etc.....

    That said, I would probably avoid anything appearing in a list of "10 most common passwords" (and probably even 100)....

    One more, just for fun:

    https://www.grc.com/haystack.htm

  • Shane (unregistered)
    automatically truncated your password to the first 8 characters

    So,

    crypt()
    with DES?

  • watcher (unregistered) in reply to random_garbage

    Excellent point sir. But then, how should it be done?

    If the database stores the salt and hashed salted password, and the connection is over HTTPS, the client would need to send the password without any hashing and have the server validate using the salt and hashed salted password.

    Or was that the whole point, that the outlined Challenge system is fundamentally flawed against database breaches in terms of preventing masquerading?

    I'm looking at it from the point of defense in depth. If HTTPS is somehow broken or bypassed, the challenge system ensures that the password is still not in the clear, at the cost of the weakness you noted?

  • watcher (unregistered) in reply to random_garbage
    random_garbage:
    Geraden:
    Instead, his client (usually a browser in the case of websites) takes his password, hashes it, then uses it as a key to encrypt a randomly generated challenge string from the server. His client sends that encrypted string, and NOT his password, to the server. Since the challenge string is random each time, the response should be different each time to. And your password is never transmitted. The server will compare your response to what it thinks the right answer is (it will encrypt the challenge string with your password hash to know what to expect) and provide authentication or access denied behaviour.
    Congratulations, your password is now just your password hash.

    All that fancy secret stuff you remember? That is just something you give to your browser to allow it to calculate your "real" password.

    An attacker doesn't need to know the fancy secret stuff to log in as you. They only need the hash. Sure, they can't use the hash to figure out the fancy secret stuff, but they don't need that. When the server sends them the challenge, they use the hash to calculate the response, and send that back. So the hash is your real password, and your fancy secret stuff is just the easy password you give your computer to have it figure out your real password.

    Oh, and it gets worse, now: your real password (the hash of the fancy stuff you're remembering) is stored in the clear on the server. No salting, no hashing, nothing. If I can see the stored hash, I can log in as you.

    Congratulations, you've just learned the first rule of crypto: don't roll your own crypto. Even if you think you know what you're doing, you're probably wrong.

    Excellent point sir. But then, how should it be done?

    If the database stores the salt and hashed salted password, and the connection is over HTTPS, the client would need to send the password without any hashing and have the server validate using the salt and hashed salted password.

    Or was that the whole point, that the outlined Challenge system is fundamentally flawed against database breaches in terms of preventing masquerading?

    I'm looking at it from the point of defense in depth. If HTTPS is somehow broken or bypassed, the challenge system ensures that the password is still not in the clear, at the cost of the weakness you noted?

    (Sorry for the double post... it didn't get quoted in the first one)

  • np (unregistered) in reply to pedant
    pedant:
    ...This is why we need salt people...

    I have my salt wife, thank you very much.

  • Manwitchestershire (unregistered) in reply to watcher
    watcher:
    Excellent point sir. But then, how should it be done?
    The server will usually issue a public key that the client uses to encrypt <whatever> before sending it to the server to decrypt and store.
  • foo AKA fooo (unregistered) in reply to hot dog
    hot dog:
    foo AKA fooo:
    faoileag:
    It seems to be a common misapprehension that taking possibilities that look "obvious" to a human away from a given set of data enhances security.

    As far as I know the germans started it in WWII - certain wheel settings where not allowed for their enigma machines, because they were considered too obvious. British military intelligence on the other hand knew about those restrictions, thus enabling Turing to crack the communication faster since he could skip combinations he knew not to be allowed.

    More precisely, the enigma would never encrypt a character to itself, thereby reducing the number of possible results from 26 to 25 and allowing them to exclude words, e.g. EET could not be encypted from DER, EIN or MIT (3 common German words).
    I thought they realised this pretty early on, and one of the changes they made was to allow mapping back to itself (I think via the plugboard?)
    The plugboard was applied both on input and output, see image. So it did increase the key space, but did not allow mapping back to itself.

  • (cs)

    Another useful link http://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/

  • Hannes (unregistered) in reply to Anon
    Anon:
    At some banks, ALL of these restrictions are in place, which means cracking a PIN can become trivial (as though the space wasn't small enough by itself!).

    Don't forget that you have only THREE tries to crack that pin before the pin card is locked.

    Not so "trivial" anymore, huh?

  • foo (unregistered) in reply to foo AKA fooo

    Joke's on you, I have a CRT tube.

    CAPTCHA: odio. CRTs certainly are odious.

  • foo (unregistered) in reply to foo AKA fooo
    foo AKA fooo:
    chubertdev:
    QJo:
    NotZeus:
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.
    It's almost like he was being sarcastic!
    Ok, so you do know the N in "PIN" means "number", right?
    I thought everybody knew these TLA abbreviations.

    Remembering all of them is a PITA arse.

    Please stop this abuse of RAS Syndrome misuse and turn off your LCD displays.

    Foo O. Fooo, CEO Officer, Department of Redundancy Department

    Joke's on you, I have a CRT tube.

    CAPTCHA: odio. CRTs certainly are odious.

    Joke's on you, I have a CRT tube.

    CAPTCHA: odio. CRTs certainly are odious.

  • Jibble (unregistered) in reply to chubertdev

    [quote user="chubertdev"][quote user="flabdablet"] are you really complaining that a free service won't let you use it if you block their ads?[/quote]

    No, but maybe they could just tell you that instead of making you sit there for an hour trying to figure out why you can't reset your own password.

  • Kemp (unregistered) in reply to faoileag
    DumbByAssociation:
    Personally, I always view policies concerning the number of characters in a password, or permissible characters, as a first rate demonstration that the organisation doesn't know what its doing - and then take my business elsewhere...

    I assume you don't use any of Microsoft's services then? Your MSN/Live/etc account passwords are truncated to 16 (or 12?) characters. That was a fun one to debug when I used to have a long password and all official logins, such as via MSN Messenger, worked fine (they truncate before sending) but all third-party apps, such as Pidgin, were complaining about my password being wrong. These days the Live website at least warns you about it if you try to sign in with a long password (it still lets you sign up with one though).

  • erinnye (unregistered) in reply to Hannes
    Hannes:
    Anon:
    At some banks, ALL of these restrictions are in place, which means cracking a PIN can become trivial (as though the space wasn't small enough by itself!).

    Don't forget that you have only THREE tries to crack that pin before the pin card is locked.

    Not so "trivial" anymore, huh?

    Only for online ATMs. Offline ones (e.g. those in foreign banks/countries, only transmitting once per day or every few hours what you did) just store the number of tries on the card. Older ones only on the magnetic stripe. Which can easily be reset...

  • F (unregistered) in reply to chubertdev
    chubertdev:
    Loose Bree:
    Stuart:
    no laughing matter:
    In the case of ATM machine PIN numbers - which are usually exactly 4 characters and these characters are digits only - it is a reasonable assumption.
    FTFY
    You're aware that the M in ATM stands for "machine", right? However prevalent a colloquialism, redundancy is still redundant.

    It's almost like he was being sarcastic!

    Here? No chance.

  • Equisetum (unregistered) in reply to DumbByAssociation
    DumbByAssociation:
    Personally, I always view policies concerning the number of characters in a password, or permissible characters, as a first rate demonstration that the organisation doesn't know what its doing - and then take my business elsewhere...

    Chance would be a fine thing. My university has the following requirements for passwords:

    . Exactly 8 characters long. . At least three types of characters (uppercase, lowercase, numbers, symbols) but NOT the following symbols £ : | \ ~ @ . Passwords cannot start with whitespace or "

    And no, I'm not changing university no matter how stupid the password requirements.

  • Evan (unregistered) in reply to Windows NT
    Windows NT:
    John:
    If I tell you my password is 14 characters long, yes you save some time not having to computer hashes for lengths 1-13, but the number of hashes you will need to brute the entire 14 char keyspace is bigger than 1-13 combined anyway.
    Wanna bet?
    I do.

    It's not a proof, but here the number of 14 character passwords as well as 1-13 character passwords for both a 62-character choice (alphanum) and an 85-character choice:

    >>> sum([62**x for x in range(14)])
    203307695650123392002283L
    >>> 62**14
    12401769434657526912139264L
    >>> sum([85**x for x in range(14)])
    12234484467962423342750186L
    >>> 85**14
    1027696695308843560791015625L

    For both, the number of 14 character passwords is two orders of magnitude higher than the number of 1-through-13 character passwords.

    watcher:
    Excellent point sir. But then, how should it be done?

    If the database stores the salt and hashed salted password, and the connection is over HTTPS, the client would need to send the password without any hashing and have the server validate using the salt and hashed salted password.

    Yep, like that.

    Theoretically you could have the client hash the password and the server salt&hash that hash, but that doesn't buy much.

Leave a comment on “Security by Password”

Log In or post as a guest

Replying to comment #:

« Return to Article