Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enforcing Different Passwords for Different Sites

diegobasch.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: Enforcing Different Passwords for Different Sites

#11

Post by PeterisP »

baak wrote: post #5

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.

Re: Enforcing Different Passwords for Different Sites

#12

Post by [deleted] »

diego wrote: post #10
georgemcbay wrote: post #9

"Now, one fine day somecrappysite.com gets hacked. The next time you visit, the web page has malicious code that sends your password in plaintext to someone. There go your Paypal funds, your Facebook account, your online life." 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 tha…

Right, but those people are the one percent. How do we help the vast majority?

[deleted]

Re: Enforcing Different Passwords for Different Sites

#13

Post by sporksmith »

diego wrote: post #8
sporksmith wrote: post #4

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 p…

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?

> 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.

Re: Enforcing Different Passwords for Different Sites

#15

Post by jtm45 »

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.

Re: Enforcing Different Passwords for Different Sites

#16

Post by georgemcbay »

diego wrote: post #8
sporksmith wrote: post #4

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 p…

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?

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.

Re: Enforcing Different Passwords for Different Sites

#17

Post by dohko »

diego wrote: post #8
sporksmith wrote: post #4

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 p…

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.

Re: Enforcing Different Passwords for Different Sites

#18

Post by georgemcbay »

diego wrote: post #10
georgemcbay wrote: post #9

"Now, one fine day somecrappysite.com gets hacked. The next time you visit, the web page has malicious code that sends your password in plaintext to someone. There go your Paypal funds, your Facebook account, your online life." 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 tha…

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.

Re: Enforcing Different Passwords for Different Sites

#20

Post by sporksmith »

dohko wrote: post #17
diego wrote: post #8

Earlier quoted context omitted.

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 ma…

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...

Post reply on HN