Don't Share Passwords Across Sites

  • Comments posted to this topic are about the item Don't Share Passwords Across Sites

  • Totally agree.

    My own strategy rather than using a password safe is that I have a fixed random-looking collection of capitals, numbers and symbols (which is actually memorable to me) into which I then incorporate parts of the name of the site I'm logging in to (should that be "in to which I'm logging?").

    Again, it may not be perfect, but it would be very difficult for a human to get from one of my passwords to the next, and even harder for a machine.

  • Using a product to store passwordss for various sites is all well and good, but many of us have multiple devices (Laptop, desktop, smart phone, tablet). Our smart phone might be Android, or iOS based, our desktops and laptops could be Windows, linux (or both). There is no one tool that serves them all, unfortunately---except for writing them down (bad!!) or memory. This is why most of us use the same (or very similar) passwords on all of our sites; both secured and unsecured. It just really isn't practical for most of us to use the one-site/one-password rule. Until there is cross platform 'password storage' (which will probably require encrypted secure cloud storage--with a password to access), re-using passwords will, unfortunately, be the rule, rather than the exception.

  • Everyone knows usename and password is not enough. Stop blaming users for your flawed security implementations.

    How about we stop reinventing the wheel and come up with a SAFE, SECURE, REUSABLE online identity. Something tied to more than just a password. Oh wait, it's already done: http://openid.net/. Seriously, I am tired of hearing about every site needing a unique 12+ character mixed case letters, numbers, symbols password, that's ridiculous and works against rational user friendliness and usability design constraints.

  • ldsudduth1 (7/29/2012)


    Using a product to store passwordss for various sites is all well and good, but many of us have multiple devices (Laptop, desktop, smart phone, tablet). Our smart phone might be Android, or iOS based, our desktops and laptops could be Windows, linux (or both). There is no one tool that serves them all, unfortunately...

    Not true,

    I used Password safe, with my safes synced by Dropbox. I have a Windows 7 desktop, an iOS phone, and a OSX Macbook, keeping my passwords synced across all of them. There are Android and *nix ports as well. I believe KeePass works the same way.

  • eric.rini (7/29/2012)


    Everyone knows usename and password is not enough. Stop blaming users for your flawed security implementations.

    How about we stop reinventing the wheel and come up with a SAFE, SECURE, REUSABLE online identity. Something tied to more than just a password. Oh wait, it's already done: http://openid.net/. Seriously, I am tired of hearing about every site needing a unique 12+ character mixed case letters, numbers, symbols password, that's ridiculous and works against rational user friendliness and usability design constraints.

    Yes and no. This isn't necessarily a bad solution, and may be the best one. But if someone cracks into your OpenID site, then they access all your information. There is some value to having different identities. I'm not sure I want my OpenID linked to my bank account.

  • We all know username + password doesnt meet the basic requirement of "something you have and something you know"... its more "something you know and something you know". If more developers were using centralized identities, it becomes cost effective to secure these centralized accounts with physical security measures rather than passwords.

    For example a physical authentication like linking an account to a mobile phone (it sends u a text with a unique key to login) or using a token like this - http://us.battle.net/support/en/article/battle-net-authenticator-faq simply cannot be cracked, no matter how irresponsible or uneducated the user is about security.

    If you had a single online presence it could be linked to a physical form of authenitcation and the web becomes a much more secure place. You can't have this though until people stop doing two things.

    - Stop blaming your users as if it is a solution to the problem.

    - Stop re-inventing the wheel when designing login portals, its too complicated and the risk is too high.

  • And if dropbox and other sites like that are blocked by policy.....then what?

  • Actually it is the sites fault for not storing passwords as one way encrypted hashes. On my site I store all user passwords as twofish encrypted a hundred times by itself and the user name. No way you can get back the original password text from the hash even if I publish the user/password file. With the password file in hand you cant even log in to my site let alone other sites. I cant believe yahoo stored passwords in clear text.

  • eric.rini (7/29/2012)


    Everyone knows usename and password is not enough. Stop blaming users for your flawed security implementations.

    How about we stop reinventing the wheel and come up with a SAFE, SECURE, REUSABLE online identity. Something tied to more than just a password. Oh wait, it's already done: http://openid.net/. Seriously, I am tired of hearing about every site needing a unique 12+ character mixed case letters, numbers, symbols password, that's ridiculous and works against rational user friendliness and usability design constraints.

    I disagree. Having a single ID (this includes things like Facebook, Google+ etc) is essentially the same thing as having a single password. If that ID is compromised, everything is compromised, there is no 'firewall' between identities. Actually it's WORSE because there is a single dashboard with record of EVERY place you use it. The potential thief/snoop doesn't even have to go looking for where you were using your account... it's right there.

    If you use that ID for posting on a lot of sites where your screen name is visible, it enables a lot of information to be extracted about you though a websearch (this is especially true if it's your real name) by potential employers, nosy or pissed off neighbors, stalkers etc.

    The sad thing is, many websites are getting lazy and moving to this model, giving you a 'choice' of Facebook, Google, OpenID etc without even the option of establishing an unrelated account.

    One more thing: if you look at the OpenID website, one of their 'advantages' is this little gem: Many OpenID providers collect and share a wide range of demographic information, including name, date of birth, location, gender and an email address. This data allows you to optimize your marketing efforts and tailor your website to better target the needs of your core audience.

    ...

    -- FORTRAN manual for Xerox Computers --

  • Come on. Get real. Using unique, strong passwords for every website that we log into sounds very good on the surface, but in reality it's just not feasible. That's the reason that people have always done it and continue to do so - even with all of the heightened security awareness these days. It's easy to stand on a soap box and preach about the benefits of doing unique passwords, but it isn't going to matter one bit. It's just not a workable solution for 95% of the people out there.

    I am registered on more websites than I can remember. Trying to remember which website has which password is next to impossible. There are even some sites that I use frequently that I have to go back and reset the password every time I use them because I can't remember the password. The sad part is, I actually have a pretty good memory. There's just too much information to reasonably keep track of all of it.

    My only recourse is to use a database of user IDs and passwords - which itself is protected and encrypted by a user ID/password. Of course, to keep it handy any time I need it, it's stored on my smart phone which, of course, poses a whole host of other problems.

    The user ID / password mechanism is a flawed system at best. Yes, there are problems with centralized identities, biometric security systems, etc. However, somewhere along the line, we're going to have to admit the reality that no security system is a hundred percent secure. If it can be created, it can be hacked. The best we can do is create a system that keeps honest people honest and forces dishonest people to work so hard that it's not worth their while.

    Whatever mechanism is used, the important thing is to use a security scheme that doesn't provide identity information for large groups of users with a single hack. It should be just as hard to get the information for a second user as it was for the first. After all: a long time X a lot of users = a really, really long time.

  • jmgroft (7/30/2012)


    The best we can do is create a system that keeps honest people honest and forces dishonest people to work so hard that it's not worth their while.

    It all boils down to this.

    Jay Bienvenu | http://bienv.com | http://twitter.com/jbnv

  • Essentially, we're in the same continuous balance of convenience vs. security against each type of threat that we always are.

    I generally agree that a passphrase document is the way to go; you can memorize (by typing, over and over and over) one very strong passphrase, and if you use something like FreeOTFE or GPG or Truecrypt, you can have limited two factor authentication as well by using both a passphrase and a keyfile (not even counting hardware two factor). It's awkward at first, but you get used to it quickly. You, however, must trust that the software you use to protect the password document is secure, as are the devices which store it and which decrypt it.

    I would also say that writing down passphrases, or parts of passphrases, is _not_ necessarily bad. Paper with passphrases on it is vulnerable to an in-person thief as well as video or photo surveillance (don't hold it up in front of an ATM, for example). Paper with passphrases on it is not, however, vulnerable to attack by someone without the ability to read the actual paper; i.e. almost all remote attackers.

    Saying "it's the site's fault" is well and good, but unless you only use sites that you somehow know passwords are stored securely on for your personal peace of mind on (and without serious flaws), whatever password you give them is always vulnerable.

    Note that almost no sites today use what would be considered "real" security against modern GPU assisted offline cracking techniques, and as Yahoo, LinkedIn, last.fm, Sony, and eHarmony have all demonstrated recently, even big sites lost entire lists of usernames and passphrases/hashes... and a single round of hashing with a salt isn't very worthwhile.

    Hashes are always vulnerable to rules-based hybrid dictionary attacks - no matter how securely the site stores it, "Password" is never going to be a good password.

  • jay-h (7/30/2012)


    Personally, I just don't trust outside organizations or companies... or their successors in interest, which may be very different, and have very different intentions for one or more parts of what they bought. OpenID in specific disturbs me - not just the shared marketing data, but also that the protocol has any provision for unencrypted sessions at all is quite frightening. "requiring" transport layer encryption is well and good, but if that layer is weak or fails or is accidentally turned off during a migration or upgrade, there's no real protection left.

    8.4.1. No-Encryption Association Sessions

    In a "no-encryption" association session, the OP sends the association MAC key in plain-text to the Relying Party. This makes it possible for an eavesdropper to intercept the key, and forge messages to this Relying Party when not using transport layer encryption. Therefore, "no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption. See Section 15.1.1 for more information.

    The MAC key sent by the OP MUST be the length specified for the requested association type, as specified in Section 6.2.

  • eric.rini (7/29/2012)


    For example a physical authentication like linking an account to a mobile phone (it sends u a text with a unique key to login) or using a token like this - http://us.battle.net/support/en/article/battle-net-authenticator-faq simply cannot be cracked, no matter how irresponsible or uneducated the user is about security.

    Not true. These are RSA based tokens, and there have been attacks on these that have been successful because the code is built on an algorithm, which can be duplicated.

    Your phone tends to be secure, but not for a particular attack. If every site used your phone, first it would be crazy annoying. Second, are you locked out if your phone dies/broken/lost/stolen?

    There isn't a totally secure method. As of now, we have a variety of schemes. Saying everyone should do X now doesn't improve security. I'd argue spending some social energy to convince people to use a password tool and multiple passwords across different sites makes more sense.

Viewing 15 posts - 1 through 15 (of 19 total)

You must be logged in to reply to this topic. Login to reply