2

I considered writing a program to do the above for websites I only intend to use for short-term use.

Improve this question
3
  • Crazy steve again.
    – Lucas Kauffman
    Commented Aug 10, 2013 at 2:47
  • Yeah, don't do this. Not only a waste of time, its not going to help when you don't have access to the program.
    – Gabriel Fair
    Commented Aug 10, 2013 at 3:12
  • Well, the point was that I would be able to remember that and implement it easily if I lost the program.
    – user29349
    Commented Aug 10, 2013 at 9:27

3 Answers 3

Reset to default
7

Yes, there's a very good reason, it's called KeePass. It's a free and open source password management application. It can automatically generate a rock-solid password for you, pair it to certain website, and store it in a securely encrypted database for which you have the key in a form of a master password.

Other than for learning purposes, don't play a crypto pro and write your own security-related programs.

Improve this answer
2
  • I think "I don't know, but use someone else's program" is kind of a non-answer.
    – user29349
    Commented Aug 10, 2013 at 9:25
  • 1
    @user29349 Oh no, I'm perfectly aware of the reason. If you write it yourself for actual usage, you will do something wrong. It's insecure and a waste of time. Honestly, others have given better answers when it comes to deeper explanations. I'm more interested in giving you and future visitors of this question a better solution next to a quick explanation.
    – Adi
    Commented Aug 10, 2013 at 10:41
3

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

Improve this answer
2
  • It is true that the slat has no difference in nature to the master password. On the canonical name I intend to use the first level above the TLD + extension. I think the likelihood a web-master realises I am using this is low enough to make this viable.
    – user29349
    Commented Aug 10, 2013 at 10:08
  • Either way, I wanted to use this on websites that have "no special characters" restrictions.
    – user29349
    Commented Aug 10, 2013 at 10:09
3

There are several good reasons not to do that:

  • A single SHA-1 instance is too fast; when deriving things from passwords you want to apply proper password hashing. The salt is a good thing, but it is only part of the equation.

  • Cryptographic algorithms should not be improvised; there are many ways to botch it. Reuse an existing password hashing algorithm which has been published and analysed and which resisted attacks for some years.

  • If you want to change your master password you lose all your site passwords. If you want to change one site password you have to change your master password. This is inadequate. For that, you need an indirection layer; say, the master password is used to encrypt a local database of stored per-site passwords (and these per-site passwords can then be completely random, or chosen by the site, or whatever). This is more crypto, so again don't do this at home.

Improve this answer
6
  • Are you suggesting the webmaster, looking at my hashed password in his database, would reverse the hash, and then reverse my hash? Is that possible in reasonable time? I'd prefer explanations rather than this flood of 'avoid crypto if at all possible', which attempts to unask the question.
    – user29349
    Commented Aug 10, 2013 at 10:17
  • @user29349 Please note that nobody is telling you to avoid crypto, we're telling you to avoid improvising crypto yourself. We're not being condescending at all, I'm sure that not even Tom Leek (Thomas Pornin, Google him) who is our #1 expert here on crypto matters would write his own crypto and user it in a production environment. As you can see, he has given you very good reasons not to do this, from security point of view and usability point of view.
    – Adi
    Commented Aug 10, 2013 at 10:36
  • I don't consider "websites I only intend to use for short-term " to be a production environment. I asked this question from personal interest and as much and more I care about why than whether.
    – user29349
    Commented Aug 10, 2013 at 11:40
  • @user29349 - I'm not absolutely sure that i understood your question correctly, but keep in mind that today (2013) one can calculate about 3 Giga SHA1 hashes per second with common hardware. That leaves a lot of room for brute-forcing.
    – martinstoeckli
    Commented Aug 10, 2013 at 13:33
  • I am entering in the "password" field of a given website a string generated from my existing password + the name of the website.
    – user29349
    Commented Aug 10, 2013 at 14:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .