Any thoughts on this password behaviour?



  • We use a web-based timesheet system from a large supplier.  When your password expires you have to change it and the process is:

    1) Enter user name, company and password
    2) Get told your password has expired and you have to change it
    3) Enter your old password, new password and verified new password
    4) It then logs you out
    5) Enter user name, company and password that you set 2 seconds ago

    Does anyone have any thoughts why the system would log you out and get you to log back in when you change password?



  • It might do it if login page is storing a md5 hash of the users password in a cookie when the user login. And each page then check this md5 checksum up against the password to verify that the user have entered the correct password.

     


  • @tiller said:

    It might do it if login page is storing a md5 hash of the users password in a cookie when the user login. And each page then check this md5 checksum up against the password to verify that the user have entered the correct password.

     
    You mean we don't even have to break the hash to use the password? That's awesome.



  • @RTapeLoadingError said:

    We use a web-based timesheet system from a large supplier.  When your password expires you have to change it and the process is:

    1) Enter user name, company and password
    2) Get told your password has expired and you have to change it
    3) Enter your old password, new password and verified new password
    4) It then logs you out
    5) Enter user name, company and password that you set 2 seconds ago

    Does anyone have any thoughts why the system would log you out and get you to log back in when you change password?

    If it makes you feel better, the Atlas Media Console does exactly that. I'm not sure if there's a technical reason for it.


  • Garbage Person

     No technical reason, but there is a usability one.

     

    Browser-based password saving.

    Logging you out right after you change your password makes you remember that you need to enter a new password while it's fresh in their short term memory. J. Random Idiot trying to start a new session the next day or whatever won't remember the new password because they're used to the browser remembering it for them.



  • @Weng said:

     No technical reason, but there is a usability one.

     

    Browser-based password saving.

    Logging you out right after you change your password makes you remember that you need to enter a new password while it's fresh in their short term memory. J. Random Idiot trying to start a new session the next day or whatever won't remember the new password because they're used to the browser remembering it for them.

     

    That's a very reasonable suggestion.  Given the way the rest of the product works it's probably way off the mark.



  • Passwords expiring in the first place is the real WTF.

    If my password never expires I can pick a really good one. I can remember it without writing it down.

    If I am forced to keep changing my password I firstly have to compromise, and might have to write it down and it's highly likely I'll forget which one I'm using.

     



  • @Cbuttius said:

    Passwords expiring in the first place is the real WTF.

    If my password never expires I can pick a really good one. I can remember it without writing it down.

    If I am forced to keep changing my password I firstly have to compromise, and might have to write it down and it's highly likely I'll forget which one I'm using.

     

    You'd hate having a shell account on our servers then. Your password must have at least one uppercase letter that isn't the first character, one special character, one lowercase letter and one number that isn't the last character with a minimum length of 9 characters. Passwords expire every 90 days and a perpetual hash of the last 4 passwords is stored so doing minor mutations of previous passwords is prevented. It'll also disallow having dictionary words unless you have 4+ separate words, and the minimum password age before it can be changed again is 3 days. However, for environments that don't require the level of security shell access to our servers requires I'd have to agree with the no-expire statement.



  • @Lingerance said:

    Your password must have at least one uppercase letter that isn't the first character, one special character, one lowercase letter and one number that isn't the last character with a minimum length of 9 characters. Passwords expire every 90 days and a perpetual hash of the last 4 passwords is stored so doing minor mutations of previous passwords is prevented. It'll also disallow having dictionary words unless you have 4+ separate words, and the minimum password age before it can be changed again is 3 days.
     

    So basically everyone has their password written on a yellow postit stuck to their monitor?



  • @Lingerance said:

    @Cbuttius said:

    Passwords expiring in the first place is the real WTF.

    If my password never expires I can pick a really good one. I can remember it without writing it down.

    If I am forced to keep changing my password I firstly have to compromise, and might have to write it down and it's highly likely I'll forget which one I'm using.

     

    You'd hate having a shell account on our servers then. Your password must have at least one uppercase letter that isn't the first character, one special character, one lowercase letter and one number that isn't the last character with a minimum length of 9 characters. Passwords expire every 90 days and a perpetual hash of the last 4 passwords is stored so doing minor mutations of previous passwords is prevented. It'll also disallow having dictionary words unless you have 4+ separate words, and the minimum password age before it can be changed again is 3 days. However, for environments that don't require the level of security shell access to our servers requires I'd have to agree with the no-expire statement.
    So your highly valuable systems have a password policy that guarantees that they cannot be memorized.  How exactly does that make them more secure?  Please tell me that there is some sort of SSO instead of each server having it's own passwords.


  • @b-redeker said:

    So basically everyone has their password written on a yellow postit stuck to their monitor?
    Might want to reread what I said the passwords are used for. Everyone who has shell access to the servers has no issue remembering the passwords, and if they do it's usually 5 minutes for someone else to reset their password.



  • @Jaime said:

    So your highly valuable systems have a password policy that guarantees that they cannot be memorized.  How exactly does that make them more secure?  Please tell me that there is some sort of SSO instead of each server having it's own passwords.
    Nah, passwords are only requested when privilege escalations are needed, PK auth is done for access to the servers. As for memorization, no-one has had issues, the main complaint is that it's difficult to come up with a new password that meets the requirements. Not all of the requirements I agree with either, however they all come from either: PCI/DSS, CTO's ruling for stricter passwords and side-effects of the modules used to accomplish the other two. I'd love to make it so we didn't need all 4 character classes if we had a longer password (which the module responsible for the character class checks can do), but that's never been approved. Oddly enough the CTO actually hates some of the restrictions more than I do, despite the restrictions he mentioned specifically to implement being his idea he hasn't approved my requests to lax them, nor has he given me orders to lax any of the rules and thus for reasons unknown to me the status quo is such and the one person who can authorize a change doesn't even when it's obvious to everyone else he wants it changed.



  • @b-redeker said:

    @Lingerance said:

    Your password must have at least one uppercase letter that isn't the first character, one special character, one lowercase letter and one number that isn't the last character with a minimum length of 9 characters. Passwords expire every 90 days and a perpetual hash of the last 4 passwords is stored so doing minor mutations of previous passwords is prevented. It'll also disallow having dictionary words unless you have 4+ separate words, and the minimum password age before it can be changed again is 3 days.
     

    So basically everyone has their password written on a yellow postit stuck to their monitor?

    I'm always amazed that security folks think that making you rotate unrememberable passwords makes systems more secure yet the password on your ATM card, with which you can access actual money, NEVER expires. Imagine folks putting postit's on their local ATM?

     



  • @snoofle said:

    I'm always amazed that security folks think that making you rotate unrememberable passwords makes systems more secure yet the password on your ATM card, with which you can access actual money, NEVER expires. Imagine folks putting postit's on their local ATM?
     

    password = 1-factor

    ATM card = 2-factor

     

    Not that you are incorrect about the unrememberable passwords (because shit, I put my unrememberable passwords on a note, except the really important stuff), just that you downplay ATM card security when it's not comparable to a single password like that.



  • @snoofle said:

    I'm always amazed that security folks think that making you rotate unrememberable passwords makes systems more secure yet the password on your ATM card, with which you can access actual money, NEVER expires. Imagine folks putting postit's on their local ATM?
    ATMs use two-part security, so the password doesn't need to be secure on its own. As long as you have your card, it doesn't help someone to have the pin.

    That said, you're quite right about the top-drawer-of-the-desk being a security risk. [Rambling uninteresting anecdote snipped -- easy reader version: see company do stupid, see stupid get changed for once.]



  • @snoofle said:

    I'm always amazed that security folks think that making you rotate unrememberable passwords makes systems more secure yet the password on your ATM card, with which you can access actual money, NEVER expires. Imagine folks putting postit's on their local ATM?

    There was a story somewhere, I think it was notalwaysright.com, where that woman calls the bank all angry because they re-painted wall next to the ATM, and she had her PIN written there between all the graffiti. Yes, she did not remember the PIN, as "it always was there".



  • Password policy on one of our systems here:

    • Not the same as the last 24 passwords (with a 90-day expiration, that's 6 years?)
    • Not similar to your login name
    • Not similar to your name
    • Not similar to other commonly used passwords
    • At least 2 uppercase characters
    • At least 2 lowercase characters
    • At least 2 numeric digits
    • At least 2 special characters
    • No keyboard patterns like 'qwerty'
    • At least 15 characters
    Personal notes:
    • 15 characters ensures no old style hashes on Windows 2000 or later based systems.
    • I don't know how enforceable these are by filters/automation; it would seem hard to do 'other commonly-used' and perhaps 'keyboard patterns'
    • Most systems require *1* special, upper, lower, number; I guess using two makes it more secure? (by reducing the search space?)

    On-topic:

    I agree with Weng (browser password memory), but also person-memory: it forces the user to type the password YET AGAIN so it starts becoming muscle-memory?



  • @Lingerance said:

    @b-redeker said:
    So basically everyone has their password written on a yellow postit stuck to their monitor?
    Might want to reread what I said the passwords are used for. Everyone who has shell access to the servers has no issue remembering the passwords, and if they do it's usually 5 minutes for someone else to reset their password.

    "Shell access to the servers" could mean the greasy intern who's assigned to swap backup tapes. It's pretty meaningless as far as describing what the passwords are for. I mean, I get what you're saying, but I had shell access to a Netware server when I was a greasy intern, so I could swap backup tapes, but it doesn't mean I knew anything about the system or was qualified to operate the server otherwise.

    Also, it's a mistake to assume "well, people with shell access are naturally more concerned about security" (and also imply they're better at memorizing things? WTF?). Depending on the company, some of those people could be the older-than-dirt ex-Unix pre-Internet guys who have absolutely no conception of security other than physical security. I've worked with those guys before, and I can guarantee they're no better at remembering passwords than anybody else.

    In short, don't be so snide. Your explanation was vague, and other people don't share your unbelievably strange belief that people assigned shell access suddenly increase their capacity to memorize passwords.



  • @Lingerance said:

    @b-redeker said:
    So basically everyone has their password written on a yellow postit stuck to their monitor?
    Might want to reread what I said the passwords are used for. Everyone who has shell access to the servers has no issue remembering the passwords, and if they do it's usually 5 minutes for someone else to reset their password.
    So are you saying that everyone that has any reason to have shell access to your servers has Rain-Man-like memory? And that we should all have known that?



  • @Cbuttius said:

    Passwords expiring in the first place is the real WTF.

    If my password never expires I can pick a really good one. I can remember it without writing it down.

    If I am forced to keep changing my password I firstly have to compromise, and might have to write it down and it's highly likely I'll forget which one I'm using.

     

     

    That's crazy talk dude.  If you don't rotate your password, somebody might phish you, then wait a month, then log in to the timesheet system and report that you worked on a project that you actually didn't work on.  You don't want your hours being reported against the wrong project, do you?



  • The student passwords for the college I work for expire once every year. And students forget them anyway.

    I had about 4 dozen people at my desk asking for a new password today. (I wish I was exaggerating)



    We get enough employees at our desk too.



  • Heh. I've always hated the MicroSoap way of "password complexity", I love to use long but "simple" passwords like yappakamedappahameha or $h1tty5t00f that are pretty much out of the dictionary attack range. Yet some systems disable symbols, then ask for upper/lowercase combos and numbers. The worst offender is RACF, of course: it actually checks if you used the same characters in the same position you put them... on your old password. Fortunately, I store all my passwords on the blackberry passwordkeeper :)



  • @danixdefcon5 said:

    Fortunately, I store all my passwords on the blackberry passwordkeeper :)

    This is the why password complexity rules are almost meaningless.  As soon as a system has a complex enough password selection process, then the passwords go into some type of password vault.  All an attacker needs to do is compromise the vault and they get all of the passwords.  So, the true password complexity to enter any system can be never be more than the complexity rules on whatever password keeper is the weakest among all of the admins that have a password to this system.

    Any security professional that thinks making the password policy tougher (as long at it isn't trivial) will have any real world effect is deluding himself.  As usual, squeezing tighter results in less control, not more.  Besides, if you have account lockout set up properly then an on-line brute force or dictionary attack is impossible.  Why make everybody's life more difficult trying to prevent an attack that already has an effective prevention mechanism in place?  As for off-line brute force attacks, we already know from other discussions on this board that UNIX-like systems use a computationally expensive password hashing mechanism that makes it impossible to brute force any reasonable password policy.  Something as innocuous as eight characters including upper, lower, and digits is more than satisfactory to guard against an attacker with an army of PlayStations that stole your hashed password database for at least 1000 years.  Heck, the guys that forged an MD5 signed SSL certificate needed a CA with poor policies, six months, and 200 PlayStations.



  • Agreed. While I understand some of the password policies, like mixing letters and numbers, and not having something as stupid as 'god', 'password' or dictionary words as the only thing in your password, the really really obscure password policies actually rip a hole in security. Ideally, we should be using some kind of PK authentication, and users should be carrying some kind of smartcard with the actual private key, and then that requiring a password to be decrypted. It shifts the password to the physical device, so that password (or passphrase) can be kept for much longer than a password hash in a server. If I lose my smartcard, I know that security has been compromised, and I can report it so it can get locked out as soon as it happens.

    Of course, these things are expensive, so it isn't exactly widespread. Most PK auth systems have the private key stored in a PKCS12 file, or in a "private keystore" of some kind.



  •  @Jaime said:

    So your highly valuable systems have a password policy that guarantees that they cannot be memorized.

     It's actually easy to create passwords that are very difficult to break but easy to remember.  I use a simple system:

    1. Pick a phrase that you already remember, with as many words as you want characters in the final password.  I spent a year or so just going through the lyrics of "Hotel California" with my passwords.

    2. Take the first letter of each word.

    3. Create a set of rules for adding caps, symbols, numbers.  I generally do 2-4 rules total. Optional, but it makes the pass a lot stronger.

    The goal is not (immediately) to memorize the password, but to memorize how you created the password.  From there you can recreate it as needed.

     

    For example, one of my old passwords worked like this:

    Phrase: On a dark desert highway, cool wind in my hair

    Rule: Replace o and i with 0 and 1

    Rule: Replace a with @

    Rule: Capitalize the letter H

    On a dark desert highway, cool wind in my hair => oaddhcwimh => 0@ddHcw1mH

     

    When typing I mentally think of each word as I type the corresponding letter.  Pretty quickly it becomes second nature.



  • @Cat said:

     @Jaime said:

    So your highly valuable systems have a password policy that guarantees that they cannot be memorized.

     It's actually easy to create passwords that are very difficult to break but easy to remember.  I use a simple system:

    1. Pick a phrase that you already remember, with as many words as you want characters in the final password.  I spent a year or so just going through the lyrics of "Hotel California" with my passwords.

    2. Take the first letter of each word.

    3. Create a set of rules for adding caps, symbols, numbers.  I generally do 2-4 rules total. Optional, but it makes the pass a lot stronger.

    The goal is not (immediately) to memorize the password, but to memorize how you created the password.  From there you can recreate it as needed.

     

    For example, one of my old passwords worked like this:

    Phrase: On a dark desert highway, cool wind in my hair

    Rule: Replace o and i with 0 and 1

    Rule: Replace a with @

    Rule: Capitalize the letter H

    On a dark desert highway, cool wind in my hair => oaddhcwimh => 0@ddHcw1mH

     

    When typing I mentally think of each word as I type the corresponding letter.  Pretty quickly it becomes second nature.

    Now, imagine you have ten of those password, each on systems with different restrictions, and you have to change them every 30 days.  Remebering the phrases isn't any easier than remembering passwords.  The real solution for end users is Single Sign-On, so you only have to remember one password, but admins need local passwords in case the network is broken.

    Also, how many brute force tools do you think have started adding the characters that are common letter substitues (i=1, A=4, E=3, I=!, B=8, etc...) to augment dictionary attacks?  If I want a real password, I just whip out my iPhone, tell it to make me a truely ugly dictionary-proof password, and add it to the database.  I can pass anybody's password restrictions, but my passwords are only as strong as my master password, which isn't controlled by the company.  I'm security concious, so there shouldn't be any problems.  But, somebody out there probably has passwords to your system stored in a password manager with a master password of "12345".  The whole exercise is pointless.  We need to admit that passwords are dead and it's time for every computer to come with a smart card reader and every OS to be smart card enabled by default.



  • @Jaime said:

    Now, imagine you have ten of those password, each on systems with different restrictions, and you have to change them every 30 days.  Remebering the phrases isn't any easier than remembering passwords.

    It's much easier actually.  I DO have access to many systems, and by regulations I can't ever duplicate sign-ins, since these are for different customers and if one got compromised it should not enable anyone to compromise any other customer.  The thing is you don't have to learn the phrases, you pick phrases you already remember easily.  I like songs whose lyrics I know by heart because I pick one song per client and rotate my passwords through that song; it helps me remember which password is for which client and ensures I never duplicate passwords.  And since I have the lyrics for probably hundreds of songs in my memory, there's a wide variety of material to choose from.

    Also, how many brute force tools do you think have started adding the characters that are common letter substitues (i=1, A=4, E=3, I=!, B=8, etc...) to augment dictionary attacks?

    Taking the first letter of every word pretty much guarantees a dictionary attack is useless (oaddhcwimh is not going to be dictionary attacked).  The rules are just to also eliminate any brute-force method that only used lowercase.



  • @zelmak said:

    I agree with Weng (browser password memory), but also person-memory: it forces the user to type the password YET AGAIN so it starts becoming muscle-memory?
     

    The only problem with that is that the typical usage model of the system is to access it the day/hour before timesheets need to be submitted and add all your times in for that period (in our case the 15th and last day of each month).

    Another screwy password policy we have here is to do with our share save site.  The password for this site has to be exactly 5 digits and is accessed only a couple of times a year.  I found it difficult to come up with a memorable 5 digit number as the restriction immediately rules out dates as well as ATM machine PIN number.  As a result I have a non-memorable one which I have hidden away in an email.


  • Garbage Person

     @RTapeLoadingError said:

    Another screwy password policy we have here is to do with our share save site.  The password for this site has to be exactly 5 digits and is accessed only a couple of times a year.  I found it difficult to come up with a memorable 5 digit number as the restriction immediately rules out dates as well as ATM machine PIN number.  As a result I have a non-memorable one which I have hidden away in an email.

     

    Zipcode of some non-home place that you hold dear? I have a 5-digit zipcode I use to tag test data as being test data (It's unused IRL) that I'd use for that.


  • @Cat said:

    @Jaime said:

    Now, imagine you have ten of those password, each on systems with different restrictions, and you have to change them every 30 days.  Remebering the phrases isn't any easier than remembering passwords.

    It's much easier actually.  I DO have access to many systems, and by regulations I can't ever duplicate sign-ins, since these are for different customers and if one got compromised it should not enable anyone to compromise any other customer.  The thing is you don't have to learn the phrases, you pick phrases you already remember easily.  I like songs whose lyrics I know by heart because I pick one song per client and rotate my passwords through that song; it helps me remember which password is for which client and ensures I never duplicate passwords.  And since I have the lyrics for probably hundreds of songs in my memory, there's a wide variety of material to choose from.

    Also, how many brute force tools do you think have started adding the characters that are common letter substitues (i=1, A=4, E=3, I=!, B=8, etc...) to augment dictionary attacks?

    Taking the first letter of every word pretty much guarantees a dictionary attack is useless (oaddhcwimh is not going to be dictionary attacked).  The rules are just to also eliminate any brute-force method that only used lowercase.

    Completely agree. The phrase-> first letter->apply rules is my favorite method of password generation :) By the way, some things allow for absurd passwords. For instance, a (now expired) key had a password that was the first paragraph of my favorite book, but with S=$ and all vowels capitalized.



  • I don't think passwords are affective anymore, in and of themselves.  Most "hacking" these days is accomplished through social engineering and "phishing" rather than brute force attacks.  Increasingly complex "strong" passwords are, more often than not, useless in the face of a true attack.  And so many systems for which security is unnecessary (either becuase the data is non-critical, or of no value), or the systems themselves are completely contained within other systems which are already secured, "strong" password policy is simply a baby blanket.

    For example, an internal network that can only be accessed from within a secured building, entrance to which is only available to those with company issued ID cards.  It's an open cubical environment, with close knit groups and little turnover, making it impossible for a "stranger" to walk in off the streets and log into a terminal highly unlikely.  Do you REALLY need strong password policy on internal web applications in this environment?  The savvy will simply synchronize their passwords accross systems.  And anyone who could get into an internal terminal would already have recieved the accesses they needed to log into the systems.

    I think the CARD + Pin scenario, or perhaps biometric reader (fingerprint) + PIN would be the best route to go.  'Cause even if someone guesses your pin, they still need your finger to log in.  Or vice-versa.



  • @Medezark said:

    For example, an internal network that can only be accessed from within a secured building, entrance to which is only available to those with company issued ID cards.  It's an open cubical environment, with close knit groups and little turnover, making it impossible for a "stranger" to walk in off the streets and log into a terminal highly unlikely.  Do you REALLY need strong password policy on internal web applications in this environment? 
    You're right, but you're not taking it far enough. It is often less secure to have a easily overcome but relied-upon security system, because people will assume that anyone who knows a password is supposed to. If the building you describe has no passwords on the PCs, people will take much more notice of a stranger coming along.

    Compscis tend to focus on the theoretical strengths and weaknesses of systems, but actual crackers/cryptanalysts generally focus on the weaknesses of practical implementations. That's why one of the best things you can do in choosing a secure password is to alternate letters from each side of the keyboard - the most common password stealing technique is to read over your shoulder as you type it in, and that makes it a lot harder. Security starts with the users, not with the machines and software.



  • @Medezark said:

    'Cause even if someone guesses your pin, they still need your finger to log in.

    Hmm... just where did I left my cigar cutter...



  • @bannedfromcoding said:

    @Medezark said:

    'Cause even if someone guesses your pin, they still need your finger to log in.

    Hmm... just where did I left my cigar cutter...

    Which is why I favor a CARD+Password scheme rather than a biometric thingy... I'd rather lose my smartcard than my finger or my eye. Tech guys might know that retina scanners won't work if you rip the eye out of its sockets, but there's always that sucker who watched Demolition Man an thinks it'll work...


  • @danixdefcon5 said:

    @bannedfromcoding said:

    @Medezark said:

    'Cause even if someone guesses your pin, they still need your finger to log in.

    Hmm... just where did I left my cigar cutter...

    Which is why I favor a CARD+Password scheme rather than a biometric thingy... I'd rather lose my smartcard than my finger or my eye. Tech guys might know that retina scanners won't work if you rip the eye out of its sockets, but there's always that sucker who watched Demolition Man an thinks it'll work...

    You know, you could have cited a better movie. Like Minority Report.



  • @blakeyrat said:

    @danixdefcon5 said:

    @bannedfromcoding said:

    @Medezark said:

    'Cause even if someone guesses your pin, they still need your finger to log in.

    Hmm... just where did I left my cigar cutter...

    Which is why I favor a CARD+Password scheme rather than a biometric thingy... I'd rather lose my smartcard than my finger or my eye. Tech guys might know that retina scanners won't work if you rip the eye out of its sockets, but there's always that sucker who watched Demolition Man an thinks it'll work...

    You know, you could have cited a better movie. Like Minority Report.

    I really hope you were just trolling when you wrote that. Demolition Man is a classic, Minority Report was somewhere between dross and an act of butchery.



  •  One other problem with biometric devices is if someone CAN fake your metrics (e.g. a fake finger with a fingerprint they lifted from you) they now have broken your security forever.  You can't revoke a finger and issue a new one.  Every fingerprint-based system you will ever use is now potentially compromised.



  • @Weng said:

     @RTapeLoadingError said:

    Another screwy password policy we have here is to do with our share save site.  The password for this site has to be exactly 5 digits and is accessed only a couple of times a year.  I found it difficult to come up with a memorable 5 digit number as the restriction immediately rules out dates as well as ATM machine PIN number.  As a result I have a non-memorable one which I have hidden away in an email.

     Zipcode of some non-home place that you hold dear? I have a 5-digit zipcode I use to tag test data as being test data (It's unused IRL) that I'd use for that.


     Postcodes here (Australia) are four digits and where I was born (UK) they are 7 alphanumerics.

     For me finding any meaningful 5 digit number was really hard, guessable or otherwise.

     

    @Cat said:

     One other problem with biometric devices is if someone CAN fake your metrics (e.g. a fake finger with a fingerprint they lifted from you) they now have broken your security forever.  You can't revoke a finger and issue a new one.  Every fingerprint-based system you will ever use is now potentially compromised.

     

    I saw Mythbusters (so it must be true) crack a fingerprint system by lifting a fingerprint from a glass and using a touched up photocopy on the scanner.

    They did not try to photocopy someone's retina as far as I know.



  • @Cat said:

     One other problem with biometric devices is if someone CAN fake your metrics (e.g. a fake finger with a fingerprint they lifted from you) they now have broken your security forever.  You can't revoke a finger and issue a new one.  Every fingerprint-based system you will ever use is now potentially compromised.

    BTW, when MythBusters tried to break into a fingerprint-activated lock, every method they tried succeeded.  Let me repeat that to let it sink in -- every attack vector was successful with a modest amount of effort.  They contacted the manufacturer who claimed that the lock had specific defenses designed into it to protect against these attacks.  Who tests these things internally?  Is there an independent testing body you can go to?  Biometrics seems like an industry full of snake oil salesmen to me.

    Smart cards are good enough, robust, well tested, and cheap.  Why is the world holding off on smart cards and waiting for biometrics to get better?



  • @Cat said:

     One other problem with biometric devices is if someone CAN fake your metrics (e.g. a fake finger with a fingerprint they lifted from you) they now have broken your security forever.  You can't revoke a finger and issue a new one.  Every fingerprint-based system you will ever use is now potentially compromised.

    You say that, but the logic is flawed. If someone can make a fake finger that works, you can get one of those with a different fingerprint on it, and carry it around with you. This has other advantages too: to be given access to a system, you wouldn't need to have your finger scanned - they could just issue you with a fake finger with the appropriate print on it, opening up the possibility of walking around with a keychain with a dozen fake fingers on it :)



  • @Cat said:

    Taking the first letter of every word pretty much guarantees a dictionary attack is useless (oaddhcwimh is not going to be dictionary attacked).

    You do realize that I now have to make a dictionary of first letters from each word in popular phrases, right? Though a good Markov chain implementation might be just as effective.

     Speaking of Markov chains, I've made passwords by mashing together "words" generated by a Perl script, and sprinkling them with some numbers or special characters.



  • @Cat said:

    @Jaime said:

    Now, imagine you have ten of those password, each on systems with different restrictions, and you have to change them every 30 days.  Remebering the phrases isn't any easier than remembering passwords.

    It's much easier actually.  I DO have access to many systems, and by regulations I can't ever duplicate sign-ins, since these are for different customers and if one got compromised it should not enable anyone to compromise any other customer.  The thing is you don't have to learn the phrases, you pick phrases you already remember easily.  I like songs whose lyrics I know by heart because I pick one song per client and rotate my passwords through that song; it helps me remember which password is for which client and ensures I never duplicate passwords.  And since I have the lyrics for probably hundreds of songs in my memory, there's a wide variety of material to choose from.

    Also, how many brute force tools do you think have started adding the characters that are common letter substitues (i=1, A=4, E=3, I=!, B=8, etc...) to augment dictionary attacks?

    Taking the first letter of every word pretty much guarantees a dictionary attack is useless (oaddhcwimh is not going to be dictionary attacked).  The rules are just to also eliminate any brute-force method that only used lowercase.

    I think you may be missing the point.  If a password can be made up quickly and is easy to remember, then is has a low amount of entropy.  It doesn't matter how long it is or if the password technically sits in the middle of a 10^300 keyspace, the whole "first letter of a phrase" idea is popular and likely to be succumb to automated tools.  A quick look at a dictionary gives the impression that the distribution of first letters of english words is not good for cryptographic purposes.  John the Ripper has a rules mode that would allow you to sort the alphabet by frequency of first letter use and do the mangling that you describe with very little effort.  Here is a paper on this topic that finds mnemonic passwords only slightly better than words: http://sparrow.ece.cmu.edu/group/pub/kuo_romanosky_cranor_mnemonic.pdf

    Passwords fall into one of two categories: low entropy, which are both easy to remember and easy to brute force, or high entropy, which are hard to remember and hard to brute force.  There is no middle ground where you get easy memorization of a high entropy password.  You can bring the entropy threshold down if you can choose the hashing technology.  But, if you are securing a commercial system and have no control of the hashing mechanism, it is likely that a memorized password cannot keep the system sufficiently safe.



  • @RTapeLoadingError said:

    Postcodes here (Australia) are four digits and where I was born (UK) they are 7 alphanumerics.
     

    Too many websites assume 5 digit postal codes. I remember signing up to something that accepted that I was in Australia but didn't accept my postcode! I ended up putting a Q on the front of the postcode and it worked. That would then mean they can't trust that field for summarising their users, since people would enter something random.

    @RTapeLoadingError said:

    For me finding any meaningful 5 digit number was really hard, guessable or otherwise.

     I have a 12 digit favourite number so I'd just use a subset of that. Or a standard 4 digit number and add a "0" or something to the end.



  • @Zemm said:

    @RTapeLoadingError said:

    For me finding any meaningful 5 digit number was really hard, guessable or otherwise.

     I have a 12 digit favourite number so I'd just use a subset of that. Or a standard 4 digit number and add a "0" or something to the end.

    I tried dropping one of the zeroes from the 6 digit date I generally use but could never remember which one.  Granted, I should be able to get in with a maximum of two guesses but I still found this a bit unsatisfactory.

    In future I will adopt a similar system to yours.  Take my favoured date (8 digits in DDMMYYYY format) and take the first n characters.



  • That means if it's 6 digits there are likely only 732 possibilities, as the YY is likely to be either 19 or 20 and the first 4 could be any of the 366 dates including 29 February.

     



  • @davedavenotdavemaybedave said:

    @Cat said:

     One other problem with biometric devices is if someone CAN fake your metrics (e.g. a fake finger with a fingerprint they lifted from you) they now have broken your security forever.  You can't revoke a finger and issue a new one.  Every fingerprint-based system you will ever use is now potentially compromised.

    You say that, but the logic is flawed. If someone can make a fake finger that works, you can get one of those with a different fingerprint on it, and carry it around with you. This has other advantages too: to be given access to a system, you wouldn't need to have your finger scanned - they could just issue you with a fake finger with the appropriate print on it, opening up the possibility of walking around with a keychain with a dozen fake fingers on it :)
     

    But then it's not biometric anymore. If you're allowed to use a finger that's not really your finger, then it's equivalent to using a keyfob or smartcard. It's something you have, not something you are.

    As entertaining as it would be to be carrying around a keychain full of fake fingers, the point still stands: once a particular biometric vector is compromised, you can't reliably use that biometric vector for security again for anything.



  • @Cbuttius said:

    That means if it's 6 digits there are likely only 732 possibilities, as the YY is likely to be either 19 or 20 and the first 4 could be any of the 366 dates including 29 February.
     

    Maybe I should have tagged it "Simple but ineffective"

    So I need a 6+ digit number that's memorable but not date based...



  •  After reading all this I'm kinda shocked at our authentication to access root shells on our servers. You enter your login name, then insert your smart card and enter your password. The password authenticates you with the card and then the card authenticates with the system. Before that, you logged in with a certificate, so you just needed your password to decrypt your key. I think they prefer this method though as with the certificate way, you could always have a non-passworded certificate, and this way is more portable (you can login to virtually any server (some do have restrictions on where you can login from) via any PC in the company). The card also works on some doors which have electronic locks as a bonus. 


Log in to reply