Enforcing Different Passwords for Different Sites(diegobasch.com)
diegobasch.com
Enforcing Different Passwords for Different Sites
http://diegobasch.com/enforcing-different-passwords-for-different-sites
55 comments
Right, but those people are the one percent. How do we help the vast majority?
Other than education and pushing them to use a secure password manager, I'm not sure, but the solution shouldn't involve breaking existing and secure systems which are widely used even if only by a minority of users.
"widely used by a minority" <- you made my point.
Not really.
The proposed solution adds little to no real world security (see my other post about how easy it would be to guess which part is the random one which makes this system not useful unless almost all sites use it, which will never happen). Given little to no real world security gain from the described system, it certainly isn't worth breaking an existing system that works just fine and securely even if for just a minority of people.
The proposed solution adds little to no real world security (see my other post about how easy it would be to guess which part is the random one which makes this system not useful unless almost all sites use it, which will never happen). Given little to no real world security gain from the described system, it certainly isn't worth breaking an existing system that works just fine and securely even if for just a minority of people.
Find a way to push for challenge-response authentication with a token that can be put onto a USB key. No, it's not easy to change the infrastructure to handle it, but IMO, it's the best chance to have secure authentication.
"This USB key is your identity card." is a simple concept to understand, and better than a password.
"This USB key is your identity card." is a simple concept to understand, and better than a password.
[deleted]
I agree this is a major issue, and in fact was specifically covered in an earlier xkcd (http://xkcd.com/792/) than the one cited (http://xkcd.com/936/).
It might be a good idea to enforce non-password reuse, but the proposed solutions seem fairly aggravating. In particular the 'webmaster' solution of requiring inclusion of a fixed string is extremely annoying (oops, sorry users who use cryptographically derived passwords (http://passwordmaker.org/)), and doesn't solve the problem since someone with your "main" password can probably guess the "derived" password (e.g., the main password with the mandatory substring appended to the end).
My solution as a user is to just use a password manager. I use clipperz(http://clipperz.com/), but there's plenty others out there.
* Edited to remove markdown-style links. Forgot it wasn't supported here.
It might be a good idea to enforce non-password reuse, but the proposed solutions seem fairly aggravating. In particular the 'webmaster' solution of requiring inclusion of a fixed string is extremely annoying (oops, sorry users who use cryptographically derived passwords (http://passwordmaker.org/)), and doesn't solve the problem since someone with your "main" password can probably guess the "derived" password (e.g., the main password with the mandatory substring appended to the end).
My solution as a user is to just use a password manager. I use clipperz(http://clipperz.com/), but there's plenty others out there.
* Edited to remove markdown-style links. Forgot it wasn't supported here.
The point is that the mandatory substring is random and unique to you. The problem with using a password manager is that it implies that you're already savvy enough about the issue. Most people have no idea such thing exists. How could you enforce the usage of a password manager?
Well.. why not do it half client-side and half in the cloud?
For example, why not build an pwd-management application which sits in the cloud.
Have the application store in a secureDB in the cloud your encrypted list of passwords. These would be encrypted with a master pwd stored in the local pwd repository of your (mobile) browser.
The idea would be to have the browser do all the leg work for you and have the pwd management service available form anywhere.
The browser would automatically generate a new complex pwd for each new website you subscribe to, then encrypt it and send it over to the pwd mgmt app in the cloud. When you authenticate to the website, the browser queries the pwd mgmt app for the pwd of the site. The app sends it to the client.
In this whole process the whole encryption/decrpytion happens locally, thus limiting the attack surface. It would be easy to use and overall seamlessly integrated with any device you own that has access to the internet.
Have the application store in a secureDB in the cloud your encrypted list of passwords. These would be encrypted with a master pwd stored in the local pwd repository of your (mobile) browser.
The idea would be to have the browser do all the leg work for you and have the pwd management service available form anywhere.
The browser would automatically generate a new complex pwd for each new website you subscribe to, then encrypt it and send it over to the pwd mgmt app in the cloud. When you authenticate to the website, the browser queries the pwd mgmt app for the pwd of the site. The app sends it to the client.
In this whole process the whole encryption/decrpytion happens locally, thus limiting the attack surface. It would be easy to use and overall seamlessly integrated with any device you own that has access to the internet.
That's exactly what Clipperz does :).
The main weak point is there's no way for the user to know if the javascript they're downloading is the correct Clipperz javascript, or a trojan'd version that will send my master password and decrypted database off somewhere. So, pretty much all is still lost if someone is able to break into Clipperz and modify the javascript without being noticed for a while.
A possible solution to that is to implement a browser extension to hash the javascript (and perhaps display it as a visual hash) so the user can at least easily check whether it's changed. This has been on my "possible side-project" list for a while...
The main weak point is there's no way for the user to know if the javascript they're downloading is the correct Clipperz javascript, or a trojan'd version that will send my master password and decrypted database off somewhere. So, pretty much all is still lost if someone is able to break into Clipperz and modify the javascript without being noticed for a while.
A possible solution to that is to implement a browser extension to hash the javascript (and perhaps display it as a visual hash) so the user can at least easily check whether it's changed. This has been on my "possible side-project" list for a while...
> The point is that the mandatory substring is random and unique to you.
Ah, that's a little better. I still think the security gained is not enough to justify how much of a usability problem this could be, though. Assuming the per-user fixed substring is a secret, you're basically assigning the user's password (though giving them an option to strengthen it with their own 'root' password). If it's not secret then not much security is gained.
> How could you enforce the usage of a password manager?
I don't know of a good way. Although if every site starting assigning (part of) the password, as above, I suppose that would do it.
Ah, that's a little better. I still think the security gained is not enough to justify how much of a usability problem this could be, though. Assuming the per-user fixed substring is a secret, you're basically assigning the user's password (though giving them an option to strengthen it with their own 'root' password). If it's not secret then not much security is gained.
> How could you enforce the usage of a password manager?
I don't know of a good way. Although if every site starting assigning (part of) the password, as above, I suppose that would do it.
Even if the substring is random and unique to a user it'll still be easy for an attacker to guess which part of the password that is, just like it is usually obvious which of the recaptcha words are the known and which is the unknown.
eg: mysillypasssoqpword Yeah, I think I can guess what happened there.
eg: mysillypasssoqpword Yeah, I think I can guess what happened there.
Dear god, please let me have the freedom to determine what degree of security I need on a site.
If you restrict my password options in anyway I will use your site less.
If you restrict my password options in anyway I will use your site less.
I have an algorithm for creating unique passwords.
Here is the result for HackerNews: kcahu3602122@#)*
here for Facebook: ecafu3602122@#)^
(I can create them practically in my sleep. The algorithm is personal and easy)
To determine the algorithm, one would need plain text from two sites and be able to match them. Now, everytime a site limits my freedom to creating the password I want (assuming I can't provide my own security - by demanding a capital, a number, a this a that) I default to the same password. If they get one site with my simple pass, they get all the sites on which I use it.
When you put constraints on my password creation, you make my online life MORE insecure, not less.
Free my password. Don't tell me what I can and can't do. Offer a full page of help describing to those who don't care what they should do. But don't force them.
Here is the result for HackerNews: kcahu3602122@#)*
here for Facebook: ecafu3602122@#)^
(I can create them practically in my sleep. The algorithm is personal and easy)
To determine the algorithm, one would need plain text from two sites and be able to match them. Now, everytime a site limits my freedom to creating the password I want (assuming I can't provide my own security - by demanding a capital, a number, a this a that) I default to the same password. If they get one site with my simple pass, they get all the sites on which I use it.
When you put constraints on my password creation, you make my online life MORE insecure, not less.
Free my password. Don't tell me what I can and can't do. Offer a full page of help describing to those who don't care what they should do. But don't force them.
I recommend that everyone who read this contemplates this: http://news.ycombinator.com/item?id=3889435 (AKA the voice of reason)
I am the only person I know who uses a unique, memorable and strong password for every site I use. I store all of them in my head.
I have a base password and I add the first several characters of the site to the middle.
For example:
Facebook - sdfb231a2
Hacker News - sdyc231a2
Yahoo - sdya231a2
For strong passwords I can add a suffix to further strengthen the password.
PayPal - sdpa231a2a4
I use the same suffix for all "strong" passwords. If a site requires a capital letter I always capitalize the first letter.
I've gone to create an account with a site, been told I already have an account and I get the password in 1 guess because I'm so consistent with creating them.
I don't know why everyone doesn't do this.
I have a base password and I add the first several characters of the site to the middle.
For example:
Facebook - sdfb231a2
Hacker News - sdyc231a2
Yahoo - sdya231a2
For strong passwords I can add a suffix to further strengthen the password.
PayPal - sdpa231a2a4
I use the same suffix for all "strong" passwords. If a site requires a capital letter I always capitalize the first letter.
I've gone to create an account with a site, been told I already have an account and I get the password in 1 guess because I'm so consistent with creating them.
I don't know why everyone doesn't do this.
What do you do when you log in to your bank and they tell you that your password has expired and that you need to create a new unique 6-8 character password with exactly one capital letter and one number but no special characters? And that it can't contain any part of any of your old passwords?
I guess the same thing you'd do if you ran across a site with this well intentioned but terrible idea: write it down or email it to yourself.
The only sane thing you can do as a developer is let users chose any password they like, regardless of how insecure you think it is. Store it correctly and that's the end of your involvement. Let your users do what they want, or you'll just make things worse.
I guess the same thing you'd do if you ran across a site with this well intentioned but terrible idea: write it down or email it to yourself.
The only sane thing you can do as a developer is let users chose any password they like, regardless of how insecure you think it is. Store it correctly and that's the end of your involvement. Let your users do what they want, or you'll just make things worse.
I have a standard set of characters that I add to passwords. So far Craigslist has been the only site to really throw me for a loop. I try to be consistent but I end up using 'Forgot my Password' more than I should with them.
They are the only ones.
They are the only ones.
I've done a bit of this and I suspect a few others have considered something similar, if not doing it themselves. I'm concerned about leaking a couple of these types of passwords, enough for someone to notice the pattern and apply it to the rest of your online presence. I'm sure there are black hats building personal databases of every password leak that goes by and it wouldn't be hard to do some sub-string matching to identify people making simple patterns like this.
I'm also concerned about a targeted attack against my online identity. I've had a couple of online acquaintances be the victim of targeted attacks, one holding accounts hostage as a sort of online blackmail. Someone who compromises a couple of random forums and picks up on the pattern now has the key to your online identity. I'd mitigate it somewhat by using multiple prefixes and suffixes, one set for 'throwaway' accounts and others for more important stuff. Even that tactic has issues, do you remember to change your password for that throwaway site that blew up with success and now your account is part of your online identity?
The alternatives aren't too reassuring though, I balance these risks against the possibility of my KeePass, LastPass or browser password list getting compromised.
I'm also concerned about a targeted attack against my online identity. I've had a couple of online acquaintances be the victim of targeted attacks, one holding accounts hostage as a sort of online blackmail. Someone who compromises a couple of random forums and picks up on the pattern now has the key to your online identity. I'd mitigate it somewhat by using multiple prefixes and suffixes, one set for 'throwaway' accounts and others for more important stuff. Even that tactic has issues, do you remember to change your password for that throwaway site that blew up with success and now your account is part of your online identity?
The alternatives aren't too reassuring though, I balance these risks against the possibility of my KeePass, LastPass or browser password list getting compromised.
I don't think I am interesting enough or lucrative enough for someone to expend that much effort trying to hack my accounts. If they compromise my password on one service (and presumably gain access to thousands of other passwords), if mine is unique and others aren't, I'm betting the attack (on me) stops there.
That seems like what SuperGenPass (http://supergenpass.com/) does, but with more effort and easier to break. Essentially, with SGP you type a master password into the password box and click the button in your browser (you don't have to install anything, just bookmark the javascript). It uses a one-way hash to create a unique password based on the domain.
I guess, but my method only uses my brain. I can access my accounts using an internet cafe, someone else's iPod Touch, etc.
This sparked an idea for me that I think I'll implement going forward - if you sign up with your email address and password, my server will try to login to your email account with those credentials, and if successful, say something like "hey, did you see that email [snippet of first email in inbox]". I feel this might encourage the user to use a different password.
Ha! Clever idea, but I hope you're not serious :). The most likely result would be infuriated users, and quite possibly lawsuits.
Reading someone's email without permission is a crime. Nice idea though :)
You just have to add a clause to the TOS, nobody reads it anyway so you could grant yourself a licence to do anything with their email!
Add some fine print in the user agreement, "During sign-up (only) for service X, I hereby authorize web service X to open my inbox and read one (1) email message, if I choose to provide my email account's password as my password for website X."
No longer a federal crime, maybe? Probably still get an angry mob with pitchforks outside your window.
No longer a federal crime, maybe? Probably still get an angry mob with pitchforks outside your window.
[deleted]
[deleted]
Big ol' hole here: You can't identify web apps by domain. Are you going to tell me I can't use "password123" as my password on store.foo.com and secure.foo.com (when they both point to the same database and the same user record)? Are you going to assume that passwords may be shared across all TLDs? (so I can re-use passwords on multiple separate apps on the same TLD)
It's a nice idea, but in practice, it would drive you insane because the web is not a nice uniform entity where everyone plays by a pre-arranged set of rules.
Just use LastPass and let it autogenerate passwords for you. It's stupid easy, and super effective. LastPass will even tell you how many sites you're using the same passwords on! ( https://lastpass.com/index.php?securitychallenge=1&fromw... )
It's a nice idea, but in practice, it would drive you insane because the web is not a nice uniform entity where everyone plays by a pre-arranged set of rules.
Just use LastPass and let it autogenerate passwords for you. It's stupid easy, and super effective. LastPass will even tell you how many sites you're using the same passwords on! ( https://lastpass.com/index.php?securitychallenge=1&fromw... )
Nobody gets the point. The point is that you can't force 99% of the people to use something. What I advocate is enforcement on the part of the browser and / or sites. If the user has the choice to be lazy, no solution works.
So instead of having websites that require "upper, lower, numeric and special" characters, we'll have sites that require "randomly generated word from two years ago that we hope you remember". It's just another constraint that will never be standard and will be near impossible to remember.
If you use a different password for every site, it's a given that you won't be able to remember them. Storing your passwords securely is a different problem.
The desire to enforce unique password across sites is understood. You might as well advocate all browsers to implement a builtin password manager a la LastPass and a protocol to auto-gen a password (by the site to enforce cross-site uniqueness) to be managed by the password manager. Imagine zero password fiddling signups!
Force a per site password policy on end users other than length is super annoying. The worst kind are those who restrict you to use only alpha-numeric passwords.
Down with manual password policies!
Force a per site password policy on end users other than length is super annoying. The worst kind are those who restrict you to use only alpha-numeric passwords.
Down with manual password policies!
Because browsers already optionally store passwords, adding the "password same" warning would be quite a welcome feature (or add-on), for me anyways (in mobile browsers too).
I advocate the use of password managers, but they don't offer "password same" warnings either.
My point: it's a best-practice feature option which should be implemented widely. People can turn it off if they want.
I advocate the use of password managers, but they don't offer "password same" warnings either.
My point: it's a best-practice feature option which should be implemented widely. People can turn it off if they want.
[deleted]
I'm no expert, but why does this have to be done on the password level? Why can't we just assign usernames to our own sites, and force people to login with those? I know that's incredibly annoying for a user, but it would at least guarantee the user credentials for your site are unique from any other site.
This would mean that there are two "passwords" that I have to remember - the userid and the actual password. Chances are, your site isn't worth it to remember a new uid. (I counted that only 5 out of my 150 stored account passwords are for something worth remembering anything at all.)
If you are important (say, paypal or gmail) - do two factor authentification. If you are not - don't bother me. Even creating an account is already more effort than most sites are worth.
It is equally obnoxious to generate a random string of garbage and:
* insist it's the username,
* insist it is in the password somewhere, or
* make them type the string in a third logon field
It adds friction to the process in order to solve a problem that is not "ours" to solve.
An option with less friction would be to ask them to choose a picture from 16 candidates. The 16 candidate photos would need to be generated from the username to avoid the ability to refresh the page and find the persistent image. Each image could have the random characters associated with it to be used as an addendum to the salt, or for whatever purposes on the back end which the random characters are supposed to accomplish.
* insist it's the username,
* insist it is in the password somewhere, or
* make them type the string in a third logon field
It adds friction to the process in order to solve a problem that is not "ours" to solve.
An option with less friction would be to ask them to choose a picture from 16 candidates. The 16 candidate photos would need to be generated from the username to avoid the ability to refresh the page and find the persistent image. Each image could have the random characters associated with it to be used as an addendum to the salt, or for whatever purposes on the back end which the random characters are supposed to accomplish.
After Gawker was hacked (and my account with it), I have created a website that tells average folks how to solve these issues: http://www.passmix.com/. It's not a perfect solution, but it's way better than the same password for different websites.
From what I've read this (and methods like it) seems to be a common way to generate passwords. This seems to be a somewhat weak implementation though - imagine you used this method with the same base everywhere, and 2 sites were hacked, let's called them InLinked and Kergaw. Using the examples from passmix.com with base 'house cat' I might end up with: 'housei!n8cat' and 'housek!e6cat'. Say I'm targeting you specifically, I look at these two passwords, and I see that they both follow 'houseX!Y#cat' format. It's only a moment longer before I've a good guess at how the password is constructed, and then try it against your email. Once I've cracked your email I can just use the forgot password feature of any other site to reset your password there.
It would be quite easy to write a script to detect the similarity with the two passwords (9 characters in common, same positions, same length = 12).
You should never use the same password across sites, nor should you use the same password system unless that system is secure. Assuming you can keep your algorithm for password generation private, passing this through a one-way hash function might then strengthen your password a bit (at least a hacker couldn't easily visually derive your password algorithm, or that you are using one) but this still isn't perfect.
Generally it's not a good idea to tell people how to construct passwords unless you're an expert in cryptography. I'm not, so please don't take any of this as advice on how to construct a password. It's advice on how not to, if anything.
It would be quite easy to write a script to detect the similarity with the two passwords (9 characters in common, same positions, same length = 12).
You should never use the same password across sites, nor should you use the same password system unless that system is secure. Assuming you can keep your algorithm for password generation private, passing this through a one-way hash function might then strengthen your password a bit (at least a hacker couldn't easily visually derive your password algorithm, or that you are using one) but this still isn't perfect.
Generally it's not a good idea to tell people how to construct passwords unless you're an expert in cryptography. I'm not, so please don't take any of this as advice on how to construct a password. It's advice on how not to, if anything.
This will never work for normal people.
For everyone else, there are programs like LastPass and 1Password that make this easy.
For everyone else, there are programs like LastPass and 1Password that make this easy.
[deleted](1)
I cry everytime I read these threads on HN. I've never seen such stubborness than people desperately convinced that they need to be able to memorize their passwords, or that password managers are the devil.
I'll say it again, just use a password manager. It generates random, complex passwords. It memorizes them for you. It pre-populates forms. They are locally encrypted and can be synced by themselves or with other tools. They can even be protected with two factor auth.
My mother uses LastPass. So can you.
I'll say it again, just use a password manager. It generates random, complex passwords. It memorizes them for you. It pre-populates forms. They are locally encrypted and can be synced by themselves or with other tools. They can even be protected with two factor auth.
My mother uses LastPass. So can you.
See all my other comments on this thread. Why does your mother use LastPass? How did she learn about it? How about the other 99% of the people? How do you make them use LastPass?
This is not about us.
This is not about us.
> Tell the user: your password must contain the following word: “hzru”
Enforcing this kind of thing on the masses won't make for stronger passwords, it will just have them opening up notepad.exe and saving this sites too-hard-to-remember-because-it-has-too-many-rules password on ~/Desktop/logins.txt
Enforcing this kind of thing on the masses won't make for stronger passwords, it will just have them opening up notepad.exe and saving this sites too-hard-to-remember-because-it-has-too-many-rules password on ~/Desktop/logins.txt
Now you'd have to prove that having passwords stored in a file is worse than massive password leaks. I suspect that it isn't. People already carry laptops with browsers that save passwords automatically. Losing your laptop already implies a password-change-fest.
Are you implying that browsers save passwords in cleartext? A quick search indicates that all major browsers encrypt passwords to user accounts, and some give the option of a master password as well.
They do encrypt passwords but that doesn't matter. You can still log in to their accounts and do anything you want. And if for some reason you really do want the actual passwords you can obtain those too, obviously they get decrypted to send to the website you're logging in to so just capture it at that point. Normal people don't configure master passwords.
And when they go to another computer (home/work/relatives/...) the only option is to carry that file.
One could forgo this password policy and advertise LastPass in the sign-up form for which this article's hypothetical readership is responsible.
Ok, I'll put it another way. I'm some extremely large number percent more likely to be an early adopter of your product than my mother. I will never, ever sign up with such a restriction on my password.
I don't care what we do about the rest of them. Make a bigger black list, require more complex passwords, implement better protections against brute force.
The easiest one (to use and implement) is two-factor auth, but many people lack smartphones still so it's hard to make that the easy call.
I don't care what we do about the rest of them. Make a bigger black list, require more complex passwords, implement better protections against brute force.
The easiest one (to use and implement) is two-factor auth, but many people lack smartphones still so it's hard to make that the easy call.
If you want to MAKE people use secure passwords you assign them a random password and don't allow them to choose their own. They'll write it down on a piece of paper making them pretty damn secure against almost anything except a physical break-in.
What an optimist! somecrappysite.com was probably storing your password in plaintext to begin with and it probably got pulled from the database long before you logged in again.
Having said that, this is an absolutely terrible solution for real-world usage because it inhibits people who are already security savvy from using better solutions like Stanford pwdhash or similar methods.