Encrypt PasswordMaker.rdf

[Guest]

Please add a vote for me too. Either the entire file or at least the prefix, suffix and the fields dealing with the encryption parameters should be encrypted.

Lutz

[tanstaafl]

Please add a vote for me too. Either the entire file or at least the prefix, suffix and the fields dealing with the encryption parameters should be encrypted.

Lutz

Done... you have 4 more votes Lutz...

[tanstaafl]

I forgot that you can't (yet) choose the drive/path of your settings file -- it's always stored in your browser profile. That means you must tell Firefox/Mozilla/Netscape/Flock to create profiles on your TrueCrypt volume. That's not very flexible, but at least you'll get the benefit of encrypting history, cookies, and cache, too.

Or, for the truly paranoid, you can follow the instructions in this thread on the TrueCrypt site and use the awesome custom GINA dll, and encrypt your entire User Profile using Truecrypt. This thread is kind of long, but well worth the read.

Charles

[caspian]

It's possible to encrypt PasswordMaker.rdf using the master password without comprimising the password.

Here's a suggestion for an algorithm:

1. Hash the master password using, say HMAC-SHA1.
2. Use resulting hash to seed a pseudo-random-number generator
3. Say the random number is 249. We then randomly pick characters from a list of letters, numbers, and symbols until we have a string of 249 characters.
4. We then hash the resulting string using, say HMAC-SHA256.
5. We use the resulting hash as the key to encrypt PasswordMaker.rdf using AES.

To decrypt PasswordMaker.rdf, we follow the steps 1-4 to retrieve the key, and use it to decrypt PasswordMaker.rdf.

This way, we can encrypt PasswordMaker.rdf using a key that's based off of the master password, but even if a hacker can brute-force the encrypted PasswordMaker.rdf open and retrieve the key, he's still got to brute-force the HMAC-SHA256 hash open. Then, he needs to use the resulting string to guess the pattern used by the pseudo-random number-generator to retrieve the HMAC-SHA1 hash of the master password. Finally, only after he brute forces the HMAC-SHA1 hash can he recover the master password.

We could also use this algorithm (or a similar algorithm) to verify the master password, as requested here.

[Eric H. Jung]

Hi Caspian,

Here's a suggestion for an algorithm:

1. Hash the master password using, say HMAC-SHA1.
2. Use resulting hash to seed a pseudo-random-number generator
3. Say the random number is 249. We then randomly pick characters from a list of letters, numbers, and symbols until we have a string of 249 characters.
4. We then hash the resulting string using, say HMAC-SHA256.
5. We use the resulting hash as the key to encrypt PasswordMaker.rdf using AES.

I like this idea. But how is it any better than simply using a hash of the MPW as the key? If someone knows this algorithm (it can be determined by reading the code), he can use it to reduce the security of the algorithm to its weakest point--the MPW hash. And that brings me to the same question: how is this any better than simply using a hash of the MPW as the key?

[LkonKbd]

Greetings from LeonSprings,Texas USofA,

I too would like to VOTE for this encryption of the 'PassWordMaker.RDF' file, if it is possible?

Thank you for reading this,

[tanstaafl]

Greetings from LeonSprings,Texas USofA,

I too would like to VOTE for this encryption of the 'PassWordMaker.RDF' file, if it is possible?

Done...

LkonKbd, you have two more votes...

[caspian]

I've been thinking about this for a while, and I think that I have an idea for how to encrypt passwordmaker.rdf using the MasterPassword without compromising it.

If a hacker provides the incorrect key when trying to decrypt the file, he will retrieve a bunch of "random" characters... not any more good than the encrypted file. So, he must verify whether the file has been decrypted after each brute force attempt. But what if the hacker can't verify whether the data has been successfully decrypted? Knowing the general format of the file, he'll be able to tell if he's decrypted it. For this reason, we shouldn't encrypt the entire file -- just the elements that are sensitive (the xml tags aren't sensitive... it's only what's inside the tags that needs to be encrypted)

I've been playing around with aes.js and found that it only accepts and returns numbers -- this gave me an idea. A random array of numbers is generated and this array is encrypted with a random key (the key and seeds are then discarded). Next, a pseudo-random number is chosen which is seeded with the mpw (let us call this number R). To encrypt the value used for the Leet-level, the R'th element in the encrypted array is selected. The first digit of this number is replaced with R. Finally, this modified array is encrypted with the mpw. To decrypt the string, the mpw must be provided. The pseudo-random number R is recalculated and used to extract the Leet-level.

A hacker performing a brute-force attack would have no way of knowing whether the Leet-level is anywhere within the sequence of numbers he has obtained. Other elements we wish to encrypt would be encrypted the same way by representing them with numbers -- a number would be assigned to each hashing algorithm, character set, whether to use Leet (0 or 1), etc.

Profile names, descriptions, URLs, custom character sets, etc. would not be encrypted because a hacker can verify whether these were successfully decrypted.

This method would also allow users to continue using different master passwords for different accounts.

[Eric H. Jung]

I've been thinking about this for a while, and I think that I have an idea for how to encrypt passwordmaker.rdf using the MasterPassword without compromising it.

If a hacker provides the incorrect key when trying to decrypt the file, he will retrieve a bunch of "random" characters... not any more good than the encrypted file. So, he must verify whether the file has been decrypted after each brute force attempt. But what if the hacker can't verify whether the data has been successfully decrypted? Knowing the general format of the file, he'll be able to tell if he's decrypted it. For this reason, we shouldn't encrypt the entire file -- just the elements that are sensitive (the xml tags aren't sensitive... it's only what's inside the tags that needs to be encrypted)

I've been playing around with aes.js and found that it only accepts and returns numbers -- this gave me an idea. A random array of numbers is generated and this array is encrypted with a random key (the key and seeds are then discarded). Next, a pseudo-random number is chosen which is seeded with the mpw (let us call this number R). To encrypt the value used for the Leet-level, the R'th element in the encrypted array is selected. The first digit of this number is replaced with R. Finally, this modified array is encrypted with the mpw. To decrypt the string, the mpw must be provided. The pseudo-random number R is recalculated and used to extract the Leet-level.

A hacker performing a brute-force attack would have no way of knowing whether the Leet-level is anywhere within the sequence of numbers he has obtained. Other elements we wish to encrypt would be encrypted the same way by representing them with numbers -- a number would be assigned to each hashing algorithm, character set, whether to use Leet (0 or 1), etc.

Profile names, descriptions, URLs, custom character sets, etc. would not be encrypted because a hacker can verify whether these were successfully decrypted.

This method would also allow users to continue using different master passwords for different accounts.

I can't say I follow all of this, but I can tell you that:

For this reason, we shouldn't encrypt the entire file -- just the elements that are sensitive (the xml tags aren't sensitive... it's only what's inside the tags that needs to be encrypted)

this could be a performance problem for large RDF files... don't you think?

[dirkh]

Hi,

...

I've been thinking about this for a while, and I think that I have an idea for how to encrypt passwordmaker.rdf using the MasterPassword without compromising it.

If a hacker provides the incorrect key when trying to decrypt the file, he will retrieve a bunch of "random" characters... not any more good than the encrypted file. So, he must verify whether the file has been decrypted after each brute force attempt. But what if the hacker can't verify whether the data has been successfully decrypted? Knowing the general format of the file, he'll be able to tell if he's decrypted it. For this reason, we shouldn't encrypt the entire file -- just the elements that are sensitive (the xml tags aren't sensitive... it's only what's inside the tags that needs to be encrypted)

...

I understand this in the following way:

The problem with encrypting the whole RDF file is that the XML structure provides reliable feedback as to wether a decryption attempt was successful.

This can be counered by encrypting only the data (i.e. the tag contents), not the tags or the XML syntax parts of the document.

I can't say I follow all of this, but I can tell you that:

this could be a performance problem for large RDF files... don't you think?

I don't think so. At some point during reading (btw. writing) the RDF file you have to parse the XML anyway. Decrypting only the data after parsing as opposed to decrypting the entire file should not make much of a difference.

[Miquel 'Fire' Burns]

The de/en-crypting part takes up alot of CPU power if you use a good algorithm, and in the long run, doing bits of the data can in fact make reading and writing noticeably slower compared to just doing the whole file.

[dbw784]

Add my vote to this one.

[Eric H. Jung]

Add my vote to this one.

tanstaafl, did you get that?

[eklee]

Add my vote to this one.

If the entire file is not encrypted, then at least all the Auto-Populate fields should be encrypted.  As it is right now, user/login names for auto-populate fields are not encrypted.  This could give a resourceful hacker somewhere to begin.

[tanstaafl]

tanstaafl, did you get that?

No, dang it - still not getting all of the notifications...

Doing it now...

Ok, done for both eklee and dbw784...