PasswordMaker Forums
Firefox/SeaMonkey/Mozilla/Netscape/Flock Browser Extension => Feature Requests / Enhancements => Topic started by: Eric H. Jung on November 27, 2005, 05:26:42 PM
-
Please add a vote from Gerry Miller (http://mailto:[email protected]) of Saskatoon, SK, Canada for "capability to encrypt passwdmaker.rdf...This file is normally left "wide open" since it can be read by any text editor, or notepad for that matter. Leave the capability to export in standard format as well."
Thanks,
Eric
p.s. if you want to split this into a separate post, that's fine.
-
p.s. if you want to split this into a separate post, that's fine.
I will, if only to leave it more open to discussion.
...
And the discussion begins:
I'm interpreting this as: This would only encrypt the passwordmaker.rdf file that is in someone's profile. Exporting the file would remain the same.
Right?
Of course, we could encrypt the export, but then all passwordmaker files would have to share the same encryption keys. If someone broke the encryption, we would be back at square one. We might as well leave the exports as normal text.
Oh, and this has been added to the FRL.
-
This would only encrypt the passwordmaker.rdf file that is in someone's profile.
Yes.
Of course, we could encrypt the export, but then all passwordmaker files would have to share the same encryption keys. If someone broke the encryption, we would be back at square one. We might as well leave the exports as normal tex
Not necessarily. The encryption key can be your master password. So we could provide the option to export the file both as plain text and encrypted text. The encrypted version would be useless without the master password (encryption key).
What do you think?
Oh, and this has been added to the FRL.
Thanks.
-
Of course, we could encrypt the export, but then all passwordmaker files would have to share the same encryption keys. If someone broke the encryption, we would be back at square one. We might as well leave the exports as normal text
Not necessarily. The encryption key can be your master password. So we could provide the option to export the file both as plain text and encrypted text. The encrypted version would be useless without the master password (encryption key).
What do you think?
I think that is the perfect solution.
Thanks Eric...
-
Of course, we could encrypt the export, but then all passwordmaker files would have to share the same encryption keys. If someone broke the encryption, we would be back at square one. We might as well leave the exports as normal tex
Not necessarily. The encryption key can be your master password. So we could provide the option to export the file both as plain text and encrypted text. The encrypted version would be useless without the master password (encryption key).
What do you think?
Sound good.
-
Using the Master Password as an encryption key introduces a new risk:
if the Master Password is weak, eg 2 letters, it is possible to do an exhaustive search until a valid PasswordMaker.rdf is found, revealing the Master Password in a new way, just by using the encrypted PasswordMaker.rdf and the decrypting algorithms (which are not and cannot be secret).
This might be a feature of course: users could have a solution when they forget their master password.
-
Considering, it might not be a big extra risk: the same method to find the master password also exists if you know the contents of the PasswordMaker.rdf file and a generated password.
So, one day, the FAQ "What if I forget my Master Password?" may change in:
There is a tool that exhaustively searches for you Master Password given a generated password. The processing time required depends on the quality of the hints you provide. If you still have your PasswordMaker.rdf file and only doubt on a few characters of your Master Password, you are lucky
:)
-
Using the Master Password as an encryption key introduces a new risk: if the Master Password is weak, eg 2 letters, it is possible to do an exhaustive search until a valid PasswordMaker.rdf is found, revealing the Master Password in a new way, just by using the encrypted PasswordMaker.rdf and the decrypting algorithms (which are not and cannot be secret)
The answer here is either choose a long, difficult master password or to not use the master password as the encryption key. I will make the latter optional. In other words, you will be able to choose a different password with which to encrypt passwordmaker.rdf (if you want it encrypted at all).
-
Add a big vote for me too.
I am surprised that this file is unencrypted. I noticed in the FAQ which claims that a major feature is the enormous search space created by 9 variables:
* character set
* which of nine hash algorithms was used
* date counter (if any)
* username (if any)
* password length
* password prefix (if any)
* password suffix (if any)
* which of nine l33t-speak levels was used
* when l33t-speak was applied (if at all)
which is awesome, but all of these user choices are stored out in the open. If your computer is compromised, you are left only with the master password as defense. Unfortunately, I bet most people's master password wouldn't take too long to crack using brute force methods.
Of course, storing this file in the open makes the program a dangerous place to store fixed passwords. I know you are aware of that. http://forums.passwordmaker.org/index.php?showtopic=363 (http://forums.passwordmaker.org/index.php?showtopic=363)
-
Billybob, you say:
If your computer is compromised, you are left only with the master password as defense.
I am not sure that I understand encryption a hundred percent, but I am fairly certain that the only thing needed to undo the encrypted rdf file would be the master password. So, in other words, the only thing between you and the hacker is still the master password, even if the rdf is encrypted...
-
Add a big vote for me too.
I am surprised that this file is unencrypted.
Hi billybob, your vote has been recorded.
If your computer is compromised, you are left only with the master password as defense.
I am not sure that I understand encryption a hundred percent, but I am fairly certain that the only thing needed to undo the encrypted rdf file would be the master password.
Actually, above Eric says he would allow one to use a different password, which I think is the best option anyway (especially for me, since I use different MPs for certain accounts)...
-
Romeo is right--an attacker would still only be one password away from determining all of your settings. Granted, with AES-256 encryption it could take him lifetimes to determine that password...
Unfortunately, I bet most people's master password wouldn't take too long to crack using brute force methods.
I hope you aren't right. It would be very sad indeed if people went through the trouble of using PasswordMaker only to choose a weak master password.
-
By the way, you are encouraged to use free encryption tools like TrueCrypt (http://www.truecrypt.org) to secure the settings file before encryption is natively supported. This should alleviate your concerns, BillyBob.
-
By the way, you are encouraged to use free encryption tools like TrueCrypt (http://www.truecrypt.org) to secure the settings file before encryption is natively supported. This should alleviate your concerns, BillyBob.
I totally agree with you about TrueCrypt. One of the essential programs. I have it installed on every computer I work on. Its especially valuable to me on my USB stick for my personal data and portable apps. I have left that damn thing behind so many times it is a wonder I still have it. :)
Hi billybob, your vote has been recorded.
Hi tanstaafl. Thanks. :)
-
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.
-
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
-
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...
-
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 (http://tinyurl.com/afxdn) 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
-
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 (http://forums.passwordmaker.org/index.php?showtopic=710).
-
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?
-
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,
-
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...
-
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'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?
-
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.
-
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.
-
Add my vote to this one.
-
Add my vote to this one.
tanstaafl, did you get that?
-
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, did you get that?
No, dang it - still not getting all of the notifications...
Doing it now...
Ok, done for both eklee and dbw784...
-
I vote for this feature: encrypt passwordmaker.rdf
-
Your vote has been recorded... you have 4 more, see any other features you'd like implemented?
-
So genial wie die Idee dieses Programmes ist - so naiv scheinen die Realisatoren zu sein: Nie würde ein seriöser Administrator erlauben, dass auf eine so sensitive Datei frei zugegriffen werden kann! Die Betriebssystem-Verschlüsselung nützt nichts bei einem eingeloggten aber verlassenen Arbeitsplätz, oder bei Verwendung der Anwendung auf portablen Datenträgern! Die durch Eingabe des Masterpasswortes geöffnete rdf-Datei müsste sich nach einer gewissen (einstellbaren) Zeit der nicht Nutzung wieder verschlüsseln.
Nur so wäre diese geniale Idee konsequent umgesetzt!
Dass die Verschlüsselung die meist verlangte Anforderung ist, ist aus der absolut grössten Zugriffszahl auf das Thema, 7388 mal, klar ersichtlich!
Alle meine 5 Stimmen für die Verschlüsselung!
Nur - habe ich den Eindruck, in Anbetracht dessen, dass diesbezüglich seit über drei Jahren nichts unternommen wurde, der Wille fehlt dies zu lösen, denn sonst wäre das Programm zu gut ...
Diese kritischen Anmerkungen erfolgen unter der ausdrücklichen Anerkennung und Dank für das bisher geleistete!
Translation with the help of 'Google':
So how awesome the idea of this program is - so naive the realizators seems to be: A serious administrator would never allow to use a program with free access to a such sensitive file! File encryption by the operating system does not protect when logged in but abandoned, or when using the application on portable media! The opened rdf file should, after a certain (adjustable) period of no use, became encrypted again.
Only then would this brilliant idea forceful implemented!
That encryption is the most demanded request, apparent from the absolute number of hits on the topic: 7388 times!
All my 5 votes for encryption!
But - I have the impression, in view of the fact that this has been discussed over three years, and nothing has been done, the will is lacking to solve this, because otherwise the program would be too good ...
These critical remarks are made under the explicit recognition and gratitude for what has been done!
-
Translation with the help of 'Google':
So how awesome the idea of this program is - so naive the realizators seems to be: A serious administrator would never allow to use a program with free access to a such sensitive file!
It is sensitive, yes... but since it doesn't store the actual password, the computer would have to be compromised with a keylogger to be able to ascertain the Master password, and then you have bigger problems.
In my opinion, yes, it would be nice, but it isn't necessary if you take reasonable precautions to secure physical access to your computer...
File encryption by the operating system does not protect when logged in but abandoned, or when using the application on portable media! The opened rdf file should, after a certain (adjustable) period of no use, became encrypted again.
Only then would this brilliant idea forceful implemented!
That encryption is the most demanded request, apparent from the absolute number of hits on the topic: 7388 times!
All my 5 votes for encryption!
I feel your pain (I'd love to add all 5 of my votes to my favorite FR), but sorry, only one vote per Feature per user...
But - I have the impression, in view of the fact that this has been discussed over three years, and nothing has been done, the will is lacking to solve this, because otherwise the program would be too good ...
These critical remarks are made under the explicit recognition and gratitude for what has been done!
I'm sure if it was simple, Eric would have done it a long time ago... but this is free software (LGPL), so I'm sure he would welcome patches to add this functionality if you were so inclined... :)
-
All my 5 votes for encryption!
Oh... and I did add one vote from you for it...
-
I'm sure if it was simple, Eric would have done it a long time ago... but this is free software (LGPL), so I'm sure he would welcome patches to add this functionality if you were so inclined... :)
Indeed. And patches have been submitted and accepted before by others. This is not a closed community.