neilwatson has asked for the wisdom of the Perl Monks concerning the following question:

During a discussion over at Ars about password management someone pointed out this page. The page provides an application that hashes a master password and a hostname together to produce a unique password. Using this method one never has to record any other passwords as the application will regenerate it each time you provide the master password and hostname.

Provided one uses a strong enough hash algorithim (at least SHA1) can anyone find vulnerabilities in this method of managing passwords?

Neil Watson
watson-wilson.ca

  • Comment on Password management. Seeking crypto advice

Replies are listed 'Best First'.
Re: Password management. Seeking crypto advice
by jpeg (Chaplain) on Jun 10, 2005 at 12:47 UTC
    That scheme falls apart when you have more than one password to remember per host.

    Where's the perl?

    --
    jpg
Re: Password management. Seeking crypto advice
by kaif (Friar) on Jun 10, 2005 at 14:31 UTC

    There may be a few issues:

    • Once you have computed a password for a hostname, you cannot change it. There are some workarounds, of course, like saying "hostname1" for then on, but they don't seem attractice.
    • If someone breaks your master password, all of your passwords crumble.

    But that isn't to say I haven't considered something like this myself; it's probably all-right for the low-security stuff. Were you planning to write this in Perl?

      Yes I had Perl in mind. I have some web application code that could be recycled for the hashing. One other thing that I would still have to keep track of is the username. Although I try I am not always able to use the same username for all hosts. You make good point about not being able to change the password.

      Neil Watson
      watson-wilson.ca

Re: Password management. Seeking crypto advice
by TedPride (Priest) on Jun 10, 2005 at 16:48 UTC
    This method is what most login systems use. People supply user name and password, they're checked against the database, then the user name and a unique hash generated from user name and internal site key are stored as cookies. You could also theoretically store an expiration date (48 hours?) along with the user name and create a hash based off both.

    The only problem with this system is that once a user is logged in, he stays logged in regardless of what the database says about user status. But this isn't a major problem if you check user status on every event (posting, voting, etc.) and combine that with login expiration and user check every x number of page views. You could also just ban his IP mask from Apache until his expiration runs out by using a .htaccess file:

    ErrorDocument 403 /youbanned.html order allow,deny deny from 123.456.789. allow from all