Safe Password Tutorial



  • Really glad to see that these guys are so concerned about password safety that they give the ultimate of all examples in safety:

    http://www.somrek.net/SafePassword.png

     



  •  I'll see your stupid requirements and raise you:

     



  •  Yeah, we've already discussed American Express' fail.



  •  I wonder if anyone has had this great idea:

     

    <form>

    To ensure highest security, please choose one of these secure passwords

    </form><form> <input type="radio">V2XYIst</form>

     

    <form> <input type="radio">Vcm3yzC</form>

     

    <form> <input type="radio">ngzMIW10</form>

     

    <form> <input type="radio">VmyLGwv4</form>

     

    <form> <input type="radio">Vxg2Sp</form>

     

    <form> <input type="radio">VPc5V2XY </form><form> </form><form> </form><form> </form>

    Patent Time!



  • @robbak said:

    To ensure highest security, please choose one of these secure passwords
     

    I tried that, but thought I'd be all smartlike and let a compact function create these passwords for me.

    Unfortunately, the passwords turned out to be different every time, so I scrapped that feature. It was obviously unreliable.



  • I've always wondered why none of these sites ever suggest using something like your postcode or the license plate of your car; hard to nail with a dictionary attack but easy to remember.



  • passphrases.



  • @Jake Grey said:

    I've always wondered why none of these sites ever suggest using something like your postcode
    In the US this would be a recipe for disaster.



  • @bstorer said:

    @Jake Grey said:
    I've always wondered why none of these sites ever suggest using something like your postcode
    In the US this would be a recipe for disaster.
    It's not too unique in the UK either. Average is 15 addresses per unique postcode, but it can vary from 1 to 100. And neither a postcode or a licence plate (if indeed a car is owned,) is necessarily secret from your neighbours.



  • @PJH said:

    And neither a postcode or a licence plate (if indeed a car is owned,) is necessarily secret from your neighbours.
    I think you might be edging into paranoia there; if you're something more than a random username to a cyber-criminal, a hard-to-guess password is the least of your problems.



  • @Jake Grey said:

    I've always wondered why none of these sites ever suggest using something like your postcode or the license plate of your car; hard to nail with a dictionary attack but easy to remember.


    That's good if you're worried about people trolling for random accounts, but trivially easy to break if someone's trying for your account in particular.



  • When it comes down to it, you just can't trust a user to come up with a secure password. You have to do it for them.

    That's why I wrote a program to produce random strings of length 10-15, including numbers, upper & lower case, and special characters. From this program I output over a thousand passwords, and tried to break them all with several hacking tools. The last one left standing was declared "the most secure password".

    This password is then assigned to all users, and I and they are safe in the knowledge that everyone is equally secure.

    For anyone out there interested in security, this is how it works.

    string getSecurePassword()
    {
        return "l%D9h@``.z)j&3" ; // chosen by random password generator.
                                               // guaranteed to be secure.
    }



  •  Thanks, I'll be using that password.



  • @RayS said:

     

    This password is then assigned to all users, and I and they are safe in the knowledge that everyone is equally secure.

    Communist!


  • @Heron said:

     Yeah, we've already discussed American Express' fail.

    And a much better discussion that was.  However, since y'all seem to dislike rezzing old threads, I'll comment here instead.

    @AssimilatedByBorg said:

    And thus: why, oh why, mainframe people, why have you not created a password system with less restrictions???? I mean, I know EBCDIC is an abomination, but it does have (at least some) special characters!

    Because the mainframe types are more afraid terrified of command injection attacks, and they tend to not understand which special characters can do that and which ones cannot.

    @amischiefr said:

    @dtfinch said:

    It'll take an average of 1.4 trillion login attempts There are 2.596148429267414e+33 possibilities in your to find your random 6 - 8 character password with the restrictions listed above. They'll disable your login after the first 3 or so.
     

    FTFY

    Yeah I think that it is pretty safe.  "Strong?" No, but good enough for most cases.  Plus it should take about 10.7 months to crack.

    Actually, your 2e+33 possibilities are using either case sensitivity or special characters (or both).  In real terms, with real user selected passwords, it'll take an average of around 10,000,000,0000 attempts to guess a particular user's password.  The sad thing is, that's the good 1% skewing the average tremendously there.

    Assuming we're after *a* bank account, it'll probably take an average of about 5,0000 attempts to find a password of one bank account at random, assuming you have several hundred or more accounts to attack in parallel.  And if the bank doesn't have detection for this kind of brute force attack, it's quite possible that running through all the accounts one has will take long enough that three attempts on one account will take long enough that it won't lock the account.

    Now the bad guy has broken into a hundred accounts.  The bank may have to return the money to them - but that money has to come from somewhere, so everyones loan interest goes up, their savings interest goes down, and all the bank customers suffer.  Since I have no way to check for defenses against parallel brute force attacks1, if my bank had a limit on passwords like that, I'd change banks.  Period.

    @PJH said:

    @dtfinch said:

    They'll disable your login after the first 3 or so.

    Perfect DOS. One (financial) site I use have (to use) as login,

    1. email address,
    2. password

    The last financial site I had any business beyond just being a customer had a few clues.  After 3 bad attempts on your login, they disabled your login *from that IP*, assuming a consistent IP.  It took 15 attempts from a class C network to disable it from that network.  It took 45 attempts from a class B network to disable that network.  75 failed attempts blocked you from every network you made a failed attempt from, as well as every other network that the user has not previously used to log in from.  They also had various limits for failed attempts against different accounts from the same IP.  They would not block either the primary IP address or the last IP address for a particular customer, unless there was at least one failed login attempt from that IP address during the DOS window.  Finally, they also blocked logins from any non-US IP address space to any account not owned by someone who has told the bank they're traveling outside the US (and, of course, the various sane permutations of this, with the realization that many countries do not have an IP space listed in WHOIS as theirs alone.)  Blocks were checked after the login attempt was submitted, but before the login was approved/rejected.  This all took a lot less disk space, memory, and code than I'd thought it would it would have if I'd written it.

    So, it is possible to do these things well.  Of course, this example comes from a company which allowed for UTF-8 extended characters in passwords, in addition to being case sensitive, and allowing punctuation.  Minimum password length counted characters, maximum password length counted bytes.  Maximum password length was something like 50 bytes, so few people ran into it without using UTF-8.  As of several years ago, only one customer had run into the maximum password length even with UTF-8 (and that was mostly 3 byte characters - they'd written the logging for that condition to report the number of one, two, and three byte characters used.)  So, they were almost, but not quite, entirely unlike the companies represented here.

    0 Statistic pulled out of my ass.  However, point is, number much less than the 1.4 trillion for 8 character case insensitive alphanumeric passwords.

    1 without, of course, running a parallel brute force attack, which is something I will not do.

    2 yeah, I realize that the above posters will probably not read this thread.  But at least I'm not leveling my thread necromancer.



  • @Kermos said:

    Really glad to see that these guys are so concerned about password safety that they give the ultimate of all examples in safety:
    http://www.somrek.net/SafePassword.png 

    password2 - it's twice as secure as password1. If only because it's the second entry in the dictionary list instead of the first.

    To protect your really sensitive information, set your password to password3 and experience the ultimate in computer security!



  • @tgape said:

    2 yeah, I realize that the above posters will probably not read this thread.  But at least I'm not leveling my thread necromancer.
     

    Read it. Liked it. Do you have T-shirts?



  • @tgape said:

    So, it is possible to do these things well.  Of course, this example comes from a company which allowed for UTF-8 extended characters in passwords, in addition to being case sensitive, and allowing punctuation.  Minimum password length counted characters, maximum password length counted bytes.  Maximum password length was something like 50 bytes, so few people ran into it without using UTF-8.  As of several years ago, only one customer had run into the maximum password length even with UTF-8 (and that was mostly 3 byte characters - they'd written the logging for that condition to report the number of one, two, and three byte characters used.)  So, they were almost, but not quite, entirely unlike the companies represented here.
     

    Oh man, I wish sites would universally accept UTF-8 for passwords. I'd just write my password in Japanese using like a short phrase with lots of Kanji and call it a day.



  • @Kermos said:

    Oh man, I wish sites would universally accept UTF-8 for passwords. I'd just write my password in Japanese using like a short phrase with lots of Kanji and call it a day.

    Japanese? Ptth. I'd write mine in Linear B, intermingled with VARIATION SELECTORs.



  • @Kermos said:

    @tgape said:

    So, it is possible to do these things well.  Of course, this example comes from a company which allowed for UTF-8 extended characters in passwords, in addition to being case sensitive, and allowing punctuation.  Minimum password length counted characters, maximum password length counted bytes.  Maximum password length was something like 50 bytes, so few people ran into it without using UTF-8.  As of several years ago, only one customer had run into the maximum password length even with UTF-8 (and that was mostly 3 byte characters - they'd written the logging for that condition to report the number of one, two, and three byte characters used.)  So, they were almost, but not quite, entirely unlike the companies represented here.
     

    Oh man, I wish sites would universally accept UTF-8 for passwords. I'd just write my password in Japanese using like a short phrase with lots of Kanji and call it a day.


    Why limit it to UTF-8? The websites I write will accept any sequence of byte values you can put in the "password" field, so long as you don't go over the 100kb POST limit.



  • @Carnildo said:

    Why limit it to UTF-8? The websites I write will accept any sequence of byte values you can put in the "password" field, so long as you don't go over the 100kb POST limit.

    The answer to your first question is that Nathan thought UTF-8 was good enough, and easy to do.  As the prior system was strictly numeric, stored in a 32 bit int field, UTF-8 was a decided improvement, and as Nathan demonstrated, roughly the same complexity to do as alpha-numeric.  (I think he had about 5 more lines of code for UTF-8.  Of course, that's discounting the increase in library code used.)

    As far as allowing nearly 50kb passwords...  Either you're storing something which is at least as long as the password, you're compressing the password (and thus still saving a significantly larger amount of data for ridiculous passwords), or you're storing the password in a hash.

    If you're storing your password in a hash, and that password is longer than the hash, that password is not as secure as you think it is.  You've basically maxed out the security level.  One of the key facets of hash algorithms is that they allow for multiple values to encode to the same resultant hash.  For password storing purposes, a good hash will basically guarantee that a reasonable length password will not have any other string that is either shorter than or the same length as the password encode to the same value.  However, every byte over that length multiplies the average number of multiple matches by several hundred.  The cracker no longer needs to break your password, just your hash.  Also note that unless the hash encodes the length of the encoded string, there could even be a string that's the minimum password length that'll match the hash.  If the hash *does* encode the length, then someone who gets a copy of the hash only needs to try passwords of the appropriate length, rather than having to try other lengths as well.



  • @tgape said:

    As far as allowing nearly 50kb passwords...
     

    It's silly.  If you're doing it right, your maximum password length should be 55 bytes.

     

    @tgape said:

    Either you're storing something which is at least as long as the password, you're compressing the password (and thus still saving a significantly larger amount of data for ridiculous passwords), or you're storing the password in a hash.

    All but the latter are moronic.  And permitting multi-kilobyte passwords when using a hashing algo is just wrong.



  • @PJH said:

    It's not too unique in the UK either. Average is 15 addresses per unique postcode, but it can vary from 1 to 100. And neither a postcode or a licence plate (if indeed a car is owned,) is necessarily secret from your neighbours.
     

    I used to live in a city of over 100,000 people with a single postcode. I'm not sure how that compares to the rest of Australia. There were a few double-ups on street names (some even with the same suffix, eg Sylvan Ct) within that postcode, though in different local council areas. Where I live now is just a single suburb with its own unique postcode.



  • I really hate the term "special characters." There's nothing special about them, and excluding them (or considering them special) for any reason just means you're incompetent.



  • @Scarlet Manuka said:

    To protect your really sensitive information, set your password to password3 and experience the ultimate in computer security!
     

     Choose password4 and configure it to lock your account after 3 failed attempts

    (Not all hackers use a zero indexed dictionary attack)



  • @tgape:  "Assuming we're after a bank account, it'll probably take an average of about 5,0000 attempts to find a password of one bank account at random,"

     Um, 5000 to the zeroth power is not a very large number.



  • @DWalker59 said:

    @tgape:  "Assuming we're after a bank account, it'll probably take an average of about 5,0000 attempts to find a password of one bank account at random,"

     Um, 5000 to the zeroth power is not a very large number.

    That was my first thought, which was quickly followed by "what kind of asshole uses zero-based footnotes?"  Maybe you realized this as well and were just joking.



  • @morbiuswilters said:

    That was my first thought, which was quickly followed by "what kind of asshole uses zero-based footnotes?"  Maybe you realized this as well and were just joking.

    I only use them here, and only sometimes.  But when one is leaving a footnote on a number on a site called 'the daily wtf', a zero-based footnote is so very tempting.  I found it irresistible, though, since the context was 'a number smaller than most of the people reading it would normally consider'.



  •  @tgape said:

    I found it irresistible

    To be honest, I think you should use less/fewer footnotes, because it's hard to read your otherwise +1 informative posts.



  • @dhromed said:

     @tgape said:

    I found it irresistible

    To be honest, I think you should use less/fewer footnotes, because it's hard to read your otherwise +1 informative posts.

    Agreed.

     

    Also, my distaste for zero-based counting and indexing has been well-documented on this site, but I'd like to reiterate that it is evil and gay.

     

    Finally, although tgape and I may have personal issues, I do tend to respect his posts and find them above-average in terms of content.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.