2

Reading Security Engineering by Ross Anderson, chapter 2.4.7.1 Password Manglers got an idea that finally seems to solve the issue I have with the existing 'I need to remember a strong* password for too many systems' solutions.

*) my passwords are randomly generated, with a size depending of the level of importance of the service used, with 8 characters minimum and a typical maximum of about 16 characters.


A quick breakdown of what I don't like about the existing solutions:

  • write them down : not secure, list not always accessible;
  • store them in an encrypted file : not always accessible;
  • use a dedicated software : not always accessible.


So, in short, I was looking for a solution that is:

  • always available when connected to the internet;
  • secure (nobody can steal or work out my passwords).


So, my question is:
Is it secure to use PBKDF2 to generate password, based upon my master password (12 randomly generated printable ascii characters) and using the website's domain name (stackexchange.com) as a 'salt'?

<?php
$password = $_POST['password'];
$salt = $_POST['publicIdentifier'];

function passKey($password, $salt) {
    $iterationCount = pow(2, 18); // 262.144 iterations
    $outputLength = 20; // because this should be 'secure enough'?

    // Step 1: get the derived key
    $generated = hash_pbkdf2('sha256', $password, $salt, $iterationCount, $outputLength, true); // returns binary output

    // Step 2: encode as Base91
    $generated = base91_encode($generated); // because we want 'special characters' in our password string (websites often require this)

    // Step 3: return the password, sliced down to required length
    return substr($generated, 0, $outputLength);
}
echo 'generated password: '.passKey($password, $salt);

Given that the solution would be hosted on my own trusted webserver and only accessible through SSL/TLS?


If the attacker has access to the code used (posted above), the 'publicIdentifier' and possibly a list of generated passwords, would the above scheme protect against the attacker figuring out the master password?

I'm worried that using a short, non randomly generated string as a salt could compromise the strength of PBKDF2?

5

This kind of solution has been proposed and deployed many times. It kinda works, but it has a some drawbacks:

  • If two people use the same mechanism for the same target site, then both their passwords use the same 'salt' (the server name), which is not ideal. Conceptually, you want per-site passwords so that poor security on one site does not impact your security on other sites, so you somehow assume that some of your passwords will be recovered by attackers. If 10 users use your system on the same site, and that site gets hacked, and the attacker gets all 10 passwords, then he will be able to make a parallel attack on all 10 master passwords because the 10 PBKDF2 instances will use the same salt.

    To a large extent, this issue can be fixed by using as salt the concatenation of the target site name, and your name (e.g. your email address, which is unique worldwide). Note that the salt does not need to be secret or random; what it needs is to be unique.

  • You only get one password for a given site. If the site wants to enforce a password change, and the new password must be different from the old one, then the system ceases to be applicable.

  • Many sites try to enforce "password rules" (minimum length, maximum length, presence or absence of some types of characters...). Most of these rules are remnants of traditional rituals with very little scientific justification, but they still exist. The problem is that all these rules are contradictory: there is no generation method that will produce passwords that will comply with all the sets of rules that various sites employ.

The bottom-line is that while a hash-based password generation method works, you will need to handle exceptions.

If you have a trusted Web server accessible through SSL/TLS, then maybe you could simply store your passwords there ? Possibly with some local encryption, relative to the master password that you type and send to your Web server.

  • would salt = domainname XOR randomKey work sufficiently Ok? – Monika Feb 25 '16 at 14:22
  • @Monika: if that key is hard-coded in your server, then you did not fix the case of other people (your "friends") using your server to derive their own passwords. If the key is not hard-coded in your server, then it is something that you remember, hence an extra element of the master password. – Tom Leek Feb 25 '16 at 14:24
  • 1
    Also, concatenation would be substantially better than XOR here. – Tom Leek Feb 25 '16 at 14:24
  • I just realized that one other 'feature' is missing from my scheme: it doesn't support Plausible deniability with regards to a government forcing me to disclose my passwords (maybe you could add it to your answer? because poeple may not read the comments.) – Monika Feb 27 '16 at 11:09
0

If you can access your specialized website to get your passwords, why can't you access a specialized web software to get them? LastPass, for example, offers online retrieval.

You could also carry a portable version of KeePass (and other local password managers) on a thumb drive with your database.

Or, most password managers these days have a smartphone app, so you can readily retrieve passwords from there for typing, assuming you have a smartphone and you carry it with you most places.

In other words: done right, and with a little planning, there are probably very few situations you'll find yourself in, where you CAN'T get into your password manager when you need it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.