I currently use PINs from Mirek software that is PC based. It has a nice simple interface that I keep track of all of my various passwords. Does anybody have/recommend a nice program for use with Windows Mobile 2003 SE for storing passwords?
Password Manager
- Thread starter kevnich2
- Start date
I would. There was a vulnerability released Wednesday. Not sure how it would affect CE.
Title : Schneier's PasswordSafe password validation flaw
Date : November 16, 2005
Product : PasswordSafe 1.x, 2.x
Discovered by : ElcomSoft Co.Ltd.
Overview
======================================================================
PasswordSafe is a program originally written by security expert Bruce Schneier (http://www.schneier.com) that allows one to store users' passwords in single file (called "safe") which is encrypted and protected by user's master password (called "Safe
Combination") with the Blowfish encryption algorithm. As noted on PasswordSafe web page, "the program's security has been thoroughly verified by Counterpane Labs under the supervision of Bruce Schneier, author of Applied Cryptography and creator of the Blowfish algorithm."
As noted in "Password Safe FAQ", "there is no back door in PasswordSafe to recover your Safe Combination, but there is a password-guessing program that some people have used successfully.
The program works by going through a list of possible passwords and checking each one".
However, there is a design flaw in PasswordSafe, that allows to perform Safe Combination validation a several times faster than it has been conceived by the author, which makes brute-force and dictionary attacks much more effective.
Details
======================================================================
As described in PasswordSafe documentation, the PasswordSafe database has the following format:
RND|H(RND)|SALT|IP|Name1|Password1|Notes1|...|NameN|PasswordN|NotesN
where
RND : 8-byte (64-bit) random value
H(RND) : hash value which depends on password, used along
with RND to check password (Safe Combination) validity
IP : 8-byte (64-bit) initial vector involved in
encryption/decryption process
SALT : 20-byte random value used involved in key derivation
PasswordSafe verifies password validity in following way:
bf_key = sha1 (RND | { 0x00, 0x00 } | PASSWORD); bf_block = RND; for (i=0; i<1000; i++)
bf_block = blowfish_encrypt (bf_block, bf_key); finalhash = sha1_mod (bf_block | {0x00, 0x00});
Then, the 'finalhash' is compared to 'H(RND)' and, if the're equal then the password is correct.
In pseudocode above sha1_mod() denotes usual SHA-1 computation with zeroed initial state (this seems to be an implementation error).
The above key derivation function (KDF) uses so-called key-stretching method to withstand password-guessing attacks.
This method was introduced in 1997 by Schneier, Kelsey, Hall and Wagner in "Secure Applications of Low-Entropy Keys" paper.
However, PasswordSafe contains design flaw which allows attacker to verify password validity without computing (relatively slow) KDF.
All records in PasswordSafe database are encrypted with Blowfish algorithm in CBC (Cipher Block Chaining) mode.
According to the documentation, the first block contains the length (in bytes) of encrypted data stored as 32-bit (4-byte) unsigned integer, fifth byte holds type value for current record (in PasswordSsafe 1.x, it is always zero), and three remaining bytes are zeros.
Encryption key is derived from user's password simply by computing sha1(PASSWORD | SALT). Note that this is much simpler and faster than KDF described above.
To check password for validity, the attacker can simply calculate the encryption key, decrypt first encrypted block and check if three most significant bytes are all zero.
The probability for this to occur on random password is about 2^(-24). If this is true, then the attacker can check candidate password with full KDF. Since full KDF will be called rarely (approximately 1 time per 16 million passwords), this protection against password-guessing attacks becomes absolutely useless.
With PasswordSafe 2.x, slightly more effective attack is possible. The first record of PasswordSafe 2.x database always has fixed length and type (i.e. full plaintext block is known), and this allows to check passwords with probability 2^(-64).
Impact
======================================================================
PasswordSafe is used to store sensitive data, and so the presence of such flaws may help attacker to disclose user's logins, passwords and PINs by implementing fast and effective brute-force and dictionaery attacks.
Solution/workaround
======================================================================
No known solution is available at the time of publishing this advisory.
Users should use strong passwords or passphrases. We recommend to use random alphanumeric passwords that are not shorter than 8 characters.
References
======================================================================
Bruce Schneier - Password Safe
http://www.schneier.com/passsafe.html
Password Safe FAQ
http://www.schneier.com/passsafe-faq.html
SourceForge.net: Project Info - Password Safe http://sourceforge.net/projects/passwordsafe/
Secure Applications of Low-Entropy Keys
http://www.schneier.com/paper-low-entropy.html
FIPS 180-1 - Secure Hash Standard
http://www.itl.nist.gov/fipspubs/fip180-1.htm
The Blowfish Encryption Algorithm
http://www.schneier.com/blowfish.html
Bypassing the Password Prompt (Washington Post) http://www.washingtonpost.com/wp-dyn/co...rticle/2005/10/15/AR2005101500178.html
About ElcomSoft Co.Ltd.
Title : Schneier's PasswordSafe password validation flaw
Date : November 16, 2005
Product : PasswordSafe 1.x, 2.x
Discovered by : ElcomSoft Co.Ltd.
Overview
======================================================================
PasswordSafe is a program originally written by security expert Bruce Schneier (http://www.schneier.com) that allows one to store users' passwords in single file (called "safe") which is encrypted and protected by user's master password (called "Safe
Combination") with the Blowfish encryption algorithm. As noted on PasswordSafe web page, "the program's security has been thoroughly verified by Counterpane Labs under the supervision of Bruce Schneier, author of Applied Cryptography and creator of the Blowfish algorithm."
As noted in "Password Safe FAQ", "there is no back door in PasswordSafe to recover your Safe Combination, but there is a password-guessing program that some people have used successfully.
The program works by going through a list of possible passwords and checking each one".
However, there is a design flaw in PasswordSafe, that allows to perform Safe Combination validation a several times faster than it has been conceived by the author, which makes brute-force and dictionary attacks much more effective.
Details
======================================================================
As described in PasswordSafe documentation, the PasswordSafe database has the following format:
RND|H(RND)|SALT|IP|Name1|Password1|Notes1|...|NameN|PasswordN|NotesN
where
RND : 8-byte (64-bit) random value
H(RND) : hash value which depends on password, used along
with RND to check password (Safe Combination) validity
IP : 8-byte (64-bit) initial vector involved in
encryption/decryption process
SALT : 20-byte random value used involved in key derivation
PasswordSafe verifies password validity in following way:
bf_key = sha1 (RND | { 0x00, 0x00 } | PASSWORD); bf_block = RND; for (i=0; i<1000; i++)
bf_block = blowfish_encrypt (bf_block, bf_key); finalhash = sha1_mod (bf_block | {0x00, 0x00});
Then, the 'finalhash' is compared to 'H(RND)' and, if the're equal then the password is correct.
In pseudocode above sha1_mod() denotes usual SHA-1 computation with zeroed initial state (this seems to be an implementation error).
The above key derivation function (KDF) uses so-called key-stretching method to withstand password-guessing attacks.
This method was introduced in 1997 by Schneier, Kelsey, Hall and Wagner in "Secure Applications of Low-Entropy Keys" paper.
However, PasswordSafe contains design flaw which allows attacker to verify password validity without computing (relatively slow) KDF.
All records in PasswordSafe database are encrypted with Blowfish algorithm in CBC (Cipher Block Chaining) mode.
According to the documentation, the first block contains the length (in bytes) of encrypted data stored as 32-bit (4-byte) unsigned integer, fifth byte holds type value for current record (in PasswordSsafe 1.x, it is always zero), and three remaining bytes are zeros.
Encryption key is derived from user's password simply by computing sha1(PASSWORD | SALT). Note that this is much simpler and faster than KDF described above.
To check password for validity, the attacker can simply calculate the encryption key, decrypt first encrypted block and check if three most significant bytes are all zero.
The probability for this to occur on random password is about 2^(-24). If this is true, then the attacker can check candidate password with full KDF. Since full KDF will be called rarely (approximately 1 time per 16 million passwords), this protection against password-guessing attacks becomes absolutely useless.
With PasswordSafe 2.x, slightly more effective attack is possible. The first record of PasswordSafe 2.x database always has fixed length and type (i.e. full plaintext block is known), and this allows to check passwords with probability 2^(-64).
Impact
======================================================================
PasswordSafe is used to store sensitive data, and so the presence of such flaws may help attacker to disclose user's logins, passwords and PINs by implementing fast and effective brute-force and dictionaery attacks.
Solution/workaround
======================================================================
No known solution is available at the time of publishing this advisory.
Users should use strong passwords or passphrases. We recommend to use random alphanumeric passwords that are not shorter than 8 characters.
References
======================================================================
Bruce Schneier - Password Safe
http://www.schneier.com/passsafe.html
Password Safe FAQ
http://www.schneier.com/passsafe-faq.html
SourceForge.net: Project Info - Password Safe http://sourceforge.net/projects/passwordsafe/
Secure Applications of Low-Entropy Keys
http://www.schneier.com/paper-low-entropy.html
FIPS 180-1 - Secure Hash Standard
http://www.itl.nist.gov/fipspubs/fip180-1.htm
The Blowfish Encryption Algorithm
http://www.schneier.com/blowfish.html
Bypassing the Password Prompt (Washington Post) http://www.washingtonpost.com/wp-dyn/co...rticle/2005/10/15/AR2005101500178.html
About ElcomSoft Co.Ltd.
I said I'd think about trying something else. If you can't read in context, get off the message boards.
I can read contexts just fine. Using one vulnerability as the reason is just silly. Especially since the vuln doesn't seem to be getting much play...
A known exploit with no known fix isn't a reason to explore alternatives? Ok you are right. :Q Anyways it's just put up there as FYI since it isnt' getting much play. Just how much play woudl you expect that this app would get? 
Is this a flaw the developers aren't going to fix? Were they given time to find a solution before the information was posted onto half a dozen mailing lists?
Hell, I haven't been able to find _any_ discussion on the problem.
So, what program do you recommend instead?
Who knows if it is or isn't going to be fixed. And this isn't a case of developers, it's open source, originally created by one dude. You want it fixed, fix it.
I do not recommend any password keeping program. I recommend not using one, unless there is a biometric involved, and that's obviously going to be for corporate identity management. For a home user, it's just another way you can be cracked, hacked or however else you want to put it.
It's being developped by developers now. They're actively working on it (whether they're working on this problem or not I can't tell). I don't use this one, I use one that uses the same database format. Keeping it on an encrypted disk image helps too.
Do you expect people to write down their passwords, or use easy to remember crappy ones? Either way it's more trouble than keeping GOOD passwords that are difficult to remember (and difficult to brute force) in an encrypted format.
Originally posted by: n0cmonkey
It's being developped by developers now. They're actively working on it (whether they're working on this problem or not I can't tell). I don't use this one, I use one that uses the same database format. Keeping it on an encrypted disk image helps too.
Do you expect people to write down their passwords, or use easy to remember crappy ones? Either way it's more trouble than keeping GOOD passwords that are difficult to remember (and difficult to brute force) in an encrypted format.
Agreed on encrypted disk method on the first point. On the second, I don't recommend people use easy to remember crappy passwords, but it isn't too hard to remember a complex or (several for that matter) passwords. And yes it may be more trouble than keeping complex passwords in password program. It just depends on how much trouble you want to go through to keep your information secure. I agree that there is a very remote chance of a user being exploited in the fashion mentioned above. It was just posted as FYI, and I felt it was worth mentioning, since the program was recommended.
Hell, all throughout these forums there is talk about using this or using that based on what is more secure. You know that. Either way it's not a reason not too use the program and I never said it was. If a user wants to trust a program to be the gatekeeper for all their passwords, then they have decided that their passwords aren't worth keeping as secure as they could be. That's their, and your chocie to make. There is a reason why this method is explicitly not allowed in many corporate infosec policies, and it think it's apparent why. It's just not best practice, that's all. Either way it's probably not worth much more discussion, it's going a bit farther than it needs to. We all have different methods, some more secure than others. I agree that keeping them in an encrypted disk is a great practice, however those cards weren't on the table when we started this discussion.
I don't know about you, but there are a hell of a lot of passwords I need to remember. logins for: domain, unix systems (no less than 3 logins), logins for various work interfaces and tools, work mail, home mail 1, home mail 2, home mail 3, home mail 4, school mail, PDA, laptop, mini, 2 different logins/passwords for other systems at home, pin for work, pin for 2 debit cards, online accounts at 2 banks, various vendor logins, etc.
That's just too much to remember, especially if I keep them unique and good.
Bruce Schneier disagrees with you about password best practices.
Originally posted by: n0cmonkey
I don't know about you, but there are a hell of a lot of passwords I need to remember. logins for: domain, unix systems (no less than 3 logins), logins for various work interfaces and tools, work mail, home mail 1, home mail 2, home mail 3, home mail 4, school mail, PDA, laptop, mini, 2 different logins/passwords for other systems at home, pin for work, pin for 2 debit cards, online accounts at 2 banks, various vendor logins, etc.
That's just too much to remember, especially if I keep them unique and good.
Bruce Schneier disagrees with you about password best practices.
Lol, fair enough. I cringe at the idea of Counterpane actually suggesting this method to their corporate clients, and I know quite a few that would laugh in his face for doing so. Although, now that I know about this vuln my pen tests will go much quicker if I come across one of his clients. I do like his book Applied Cryptography though.... if that counts for anything.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter