Skip to main content
Information Security

Return to Answer

deleted 108 characters in body
Source Link
bobince
bobince
  • 12.8k
  • 1
  • 28
  • 42

If the webmaster of any site you visit knows the algorithm above, it becomes possible for them to mount a brute force attack on your master password from the generated password. So for this to be a viable scheme the master password would probably have to be a long string of randomness (which would probably defeat the purpose of the scheme), or the device generating the passwords would have to have a long random key that was unlocked by the master password.

Also asIt is unclear how the "salt" fits in this - if it is random, how do you know what salt to use for a practical matterparticular site? If it isn't (ie it is a fixed secret), how does it differ from the website name may notmaster password in nature?

If you have random salt and you are storing it on the generating device, you might as well be easily determinablegenerating the whole password randomly and storing it protected on the device (like Keepass et al). Sites mayAs a practical matter this has an advantage that you have a varietyrecord of changing alternativeall the site names and addresses suchyou have keys for. Without that choosing a, it becomes difficult to remember what the canonical stringname for a site may not be easyis. For example are you going to refer to this site as "IT Security Stack Exchange", "Security StackExchange", "Security", "security.stackexchange.com", "www.security.stackexchange.com", or "user29349.someopenidprovideropenidprovider.com"...? Are you going to remember that string a year down the line, when the site has changed its address and how it presents its name a few times? An advantage of a key generator based on storage (Keepass et al) rather than deterministic generation is that at least the storage can show you what keys you've got.

If the webmaster of any site you visit knows the algorithm above, it becomes possible for them to mount a brute force attack on your master password from the generated password. So for this to be a viable scheme the master password would probably have to be a long string of randomness (which would probably defeat the purpose of the scheme), or the device generating the passwords would have to have a long random key that was unlocked by the master password.

Also as a practical matter the website name may not be easily determinable. Sites may have a variety of changing alternative names and addresses such that choosing a canonical string for a site may not be easy. For example are you going to refer to this site as "IT Security Stack Exchange", "Security StackExchange", "Security", "security.stackexchange.com", "www.security.stackexchange.com", or "user29349.someopenidprovider.com"...? Are you going to remember that string a year down the line, when the site has changed its address and how it presents its name a few times? An advantage of a key generator based on storage (Keepass et al) rather than deterministic generation is that at least the storage can show you what keys you've got.

If the webmaster of any site you visit knows the algorithm above, it becomes possible for them to mount a brute force attack on your master password from the generated password. So for this to be a viable scheme the master password would probably have to be a long string of randomness (which would probably defeat the purpose of the scheme), or the device generating the passwords would have to have a long random key that was unlocked by the master password.

It is unclear how the "salt" fits in this - if it is random, how do you know what salt to use for a particular site? If it isn't (ie it is a fixed secret), how does it differ from the master password in nature?

If you have random salt and you are storing it on the generating device, you might as well be generating the whole password randomly and storing it protected on the device (like Keepass et al). As a practical matter this has an advantage that you have a record of all the site names you have keys for. Without that, it becomes difficult to remember what the canonical name for a site is. For example are you going to refer to this site as "IT Security Stack Exchange", "Security StackExchange", "Security", "security.stackexchange.com", "www.security.stackexchange.com", or "user29349.openidprovider.com"...?

Source Link
bobince
bobince
  • 12.8k
  • 1
  • 28
  • 42

If the webmaster of any site you visit knows the algorithm above, it becomes possible for them to mount a brute force attack on your master password from the generated password. So for this to be a viable scheme the master password would probably have to be a long string of randomness (which would probably defeat the purpose of the scheme), or the device generating the passwords would have to have a long random key that was unlocked by the master password.

Also as a practical matter the website name may not be easily determinable. Sites may have a variety of changing alternative names and addresses such that choosing a canonical string for a site may not be easy. For example are you going to refer to this site as "IT Security Stack Exchange", "Security StackExchange", "Security", "security.stackexchange.com", "www.security.stackexchange.com", or "user29349.someopenidprovider.com"...? Are you going to remember that string a year down the line, when the site has changed its address and how it presents its name a few times? An advantage of a key generator based on storage (Keepass et al) rather than deterministic generation is that at least the storage can show you what keys you've got.