constant password changing silliness

17 thoughts on constant password changing silliness

1. They should use openID and let the security be someone elses problem.

2. Tell me about it.

   At work, not only do we have a mix of all possible rules (your password must have letters, numbers, special characters, capital letters, be at least 10 characters long), but we also have to change password every 2 months.

   And it has to be different from our previous 24 passwords.

3. I used to think this was completely ridiculous, but now I think it’s only 95% ridiculous. In most cases, I believe changing your password every 90 days is like playing hide-and-seek and moving to a new hiding place every 90 seconds; if you haven’t been found (hacked) it means you have a good hiding place (password).

   A good hacker, though, would get access to an account and do nothing to compromise his access until he was ready to sacrifice the account. It’s an invasion of privacy, of course, if someone hacked my Amazon account and snooped my purchase history, but as long as they don’t buy things in my name I probably won’t notice or (know that I) care.

   For corporations, it’s a different story, I think. We change our passwords every 90 days, because a hacker might only be looking for information. That’s what the password is protecting, much more so than unauthorized purchases.

4. My favourite is the stack of passwords people will end up with in their desk, all valid at one point, and usually with a number changing each time.

5. At our company, which has similar password policies, some of our business people have their password taped the bottom of their laptops, simply because it changes so often that they can’t remember them. Bruce Schnider had some really good articles, but rapid password policies basically results in more insecure passwords because you can’t possibly remember them all.

   I used to keep a password file with all my passwords. Good, unique passwords per site. And then, I got separated from my laptop for two months because of the flooding in Iowa and basically realised that it was too much. It is hard to come up with good passwords, harder still to keep track of them.

6. You’re all doing it wrong. :)

   Come up with a reasonably complex password seed – A terrible example would be P@ssw0rd.

   Now, add an incremental character or characters that denote a sequence (could be Jan, Feb, Mar etc) so that when are forced to change you just move up on that sequence. And finally, if you want to have unique passwords for each site, put something in there that indicates the site. Say, a letter indicating the site. So, in March, for Amazon.com, you’d have…

   P@ssw0rdMarA

   It’s a poor example but the point is, you can put together a system that results in very solid password complexity and be able to figure out the password without having to worry about remembering it. Just by remembering the system you use to construct passwords.

   Another tip I would make is that sometimes longer passwords are easier to remember. For example, P@ssw0rdMarchAmazon might be easier for you to remember. The only time this gets particularly annoying is when you’re typing passwords on a mobile phone. :)

7. I use Password Safe, it lets me punch in most of the arbitrary letter-number rules per site, and it automatically generates and keeps track of them for me. I’m looking for one integrated directly into my browser, but no luck so far.

   A few problems with that, I have absolutely no idea what most of my passwords are. I have backed the password database file up to high hell on pen drivers, burned CDs, and even encrypted on a Dropbox cloud account. But still, if the author ever went malicious I would be royally in trouble..

   Thank you Cliffski for keeping things (authorization-wise) simple in your games and even on this blog. It’s more human, and it _feels_ better.

8. For employers, I get it; they have data security concerns that extend beyond the individual user. But for Plimus? Why should they care? I’m using their service, and if I choose an insecure or unchanging password, the only person at risk is me. Why should my e-commerce site feel it needs to mother me? This, among several other reasons, is why I have largely dumped Plimus in favor of eSellerate.

9. I have this problem at work too. Multiple passwords with different rules on different rotating schedules (AARRGGHH!!). Tim’s suggestion helps sometimes, unless password restrictions are particularly stupid/outdated. Too much of this almost forces you to start writing things down.

10. There is a Hash Password Generator which integrates into Firefox (and something for Chrome). They don’t store passwords, mainly just use a master password plus the domain to create something unique per site. That seems to work mostly well. Those two also generate the same password as SuperGenPass (a website), so it makes it easier to coordinate.

    The problem I encountered with the Iowa thing is coordinating the passwords. I use 4 machines effectively (including the dual-boot laptop). Using a generated password makes it easier to coordinate it, but it doesn’t play well with resetting passwords frequently. A password safe tool could be easier to work with that, but then you have the coordination problem. I was lucky that I had everything in a PGP-encrypted file on a USB drive, but it still took me a few days to get something to decrypt it.

11. Portable Keepass. Works with .Net or Mono (Windows/Mac/Linux). http://keepass.info/download.html

    Dropbox.

    Secure password encryption I can get to from any of my machines. No more sticky notes under MY keyboard!

12. I was using Sxipper, but they’ll be passing on into that good night.

    Modern password execution is wrong on so many levels, and none of it is the fault of the users.

    For starters, modern research suggests that longer and familiar is better than short and arcane, simply because the added punctuation/number complexity discourages good behavior on the part of users, and going from 6-10 characters to 6-10 words provides enough added complexity to be sufficiently secure.

    Next, while the mixed form passwords are resistant to dictionary attacks (which themselves should be discouraged by throttling), that’s really only useful for specific targets, less so for retail accounts. Retail accounts are going to be compromised by keyloggers and malware, and backend insecurity, simply because they’re so much easier and so readily profitable.

    And finally, serious security practice recognizes that passwords are identifiers, and not access controls.

13. That’s one of the main reason why I left plimus long time ago. The most fun thing is that while BMT listens to what their customer says and try to fix/find a solution, Plimus ignores you, then after months/years they’re “DOH! half of our customers left us, why???” and send you emails with stupid surveys/polls…. :|

14. These “secure” password systems come from long haired Linux freaks with Metal T-shirts.

    A system like this makes (especially in an office or university enviroment) people
    write down their login-information on some paper, or asking collegues to use their
    password shortly when in panic.

    Its exaclty the oppisite of security.

    Besides: how is someone supposed the “crack” a password in an online
    service by trying a brute-force / wordbook attack?
    The most simple server-scripts could block anyone entering several test-passwords
    in a short cycle.

15. The only way to seriously intecept a password (ok, useing the name of your mother might be cracked by trying)
    is not by trying it out, but by intercepting the login process, or somehow else
    recording it.

    In this case, not even a “hard” password is saver.

16. ‘These “secure” password systems come from long haired Linux freaks with Metal T-shirts.’

    I get this all the time from my Windows IT folk. I think it is more of the paranoia that all IT security people should have. Though, it does end up being better on paper than in practice.

    “The most simple server-scripts could block anyone entering several test-passwords
    in a short cycle.”

    Sadly, most programmers don’t think about security or doing this, so there is are a lot of vulnerable software out there. I do think that security training is one of those Really Useful™ skills for developers.

17. Damocles, I’m a long haired Linux freak with metal T-shirts, and I hate the typical password system too!

    Most site developers are quite short-sighted when thinking about who is going to be entering the password and how it’ll be used. They don’t realise that if they force people to jump through hoops then they will use stick to one or two passwords across all the services they use, since it’s easier to remember one obscure term than several. This means that as soon as one is compromised, they all are. And it happens more often than it should do, these days.

    The same thing goes when it comes to storing passwords. Conventional wisdom is that you should never store the password in case your database is accessed – ok, makes sense. But then this means that if you forget your password, you can’t retrieve it, only reset it – and this in turn means that frustrated users again fall back to using 1 or 2 easy-to-remember passwords across all sites, making them insecure. At the very least they should be getting you to fill in your own password hints so that the system can prompt you.

    “The most simple server-scripts could block anyone entering several test-passwords in a short cycle.”

    Sadly, it’s not always that simple. For example, stick a sleep() call in your password handling routine on many web servers and you’ve turned a password hack attempt into a denial of service attack. So it does require a little thought.

Comments are currently closed.