Re: Decrypt fails
From: lelteto (lelteto_at_discussions.microsoft.com)
Date: Wed, 7 Sep 2005 09:31:11 -0700
If you really need to get back passwords (eg. it's an SSO = Single Sign On
application) than the problem is key management. I assume that you create the
hash data from the user's (main?) password and that would be used as the
encrypt / decrypt key for the (other) passwords stored in your DB.
What encryption are you using (AES or 3DES)? What mode (CBC or ECB)? If you
are using CAPI I assume you are using the normal PKCS padding - and I assume
that's probably where your problem lies. You may save less-than-enough of the
encrypted password data. That would explain why you see (in debugger) the
password itself correctly decrypted but the padding may not be correct.
That's one of the most-often made mistake with CAPI encryption when people
ASSUME how much data they have to store from the encryption result.
> Thanks for the response.
> First, I am creating a MD5 hash data and then using it to derive a key
> (CALG_RC2 encryption algorithm). Then I use this key to encrypt/decrypt user
> passwords. My requirement concerns more with not storing passwords in plain
> text in DB and not necessarily for authentication purposes.So, my goal is to
> not store user passwords in plain text but in some encrypted form in DB.
> "Jan Spooren" wrote:
> > Hi,
> > Which encryption algorithms are you using?
> > MD5 and MD2 are hashing algorithms and cannot be used to encrypt/decrypt.
> > Actually, since hashing algorithms can be regarded as 'one-way' encryption,
> > they are especially suited for what you want to achieve.
> > Create an MD5-hash (or better yet, a SHA-1 hash) of the password and store
> > that in the database. When a user must be authenticated, hash the password
> > that (s)he provided and compare it to the hash in the database. If they
> > mach, then the user provided the right password.
> > With this approach, nor system administrators, nor an adversary who obtained
> > the encryption password (which you will have to store _somewhere_), can
> > decrypt the user's passwords.
> > The approach as described above is still vulnerable to dictionary attacks
> > and therefore stil not very secure. (An adversary could use a dictionary of
> > typical passwords, hash those, and compare them to the hashed passwords in
> > the database in order to find your user's passwords). To avoid this,
> > generate a random string of characters when creating the user record and
> > store that (in clear text) in the database with the password hash. Now
> > append the random data (which is typically called 'salt') to the password
> > and hash that. If a user needs to be authenticated, get the salt from the
> > user's database record, append it to the password (s)he provided, hash that
> > string and compare it to the hash stored in the database.
> > Storing passwords with reversible encryption in a database is usually a bad
> > thing to do. About a year ago, I performed an ICT audit on a content
> > management system that worked this way. With the permissions set of a
> > regular user, it took me less than 25 minutes to obtain a full list of user
> > accounts and passwords. The 'content management system' had been installed
> > because management deemed NTFS permissions 'too weak' to trust, because it
> > would still allow system administrators to view the files. :-)
> > Take care,
> > Jan Spooren, CISSP, CISA, MCP
> > "jreddy" <firstname.lastname@example.org> wrote in message
> > news:45E17D25-DBDF-463A-B473-D6871F07CF52@microsoft.com...
> > > My Vc++ 6.0 application on XP encrypts/decrypts passwords before it
> > > stores/reads them in/from DB. I am using the default MS Cryptography
> > > Provider
> > > (I think it is MS Strong Crytography Provider) with MD5 hashing algorithm.
> > > While it is working fine so far, I ran into a strange situation where I
> > > found
> > > a combination of 8 characters that encrypts fine but fails to decrypt
> > > (after
> > > decryption, I can see the plain text OK in debugger but I also see some
> > > garbage appended to it. CryptDecrypt returns a NTE_BAD_DATA). I have not
> > > see
> > > any other password encryption/decryption fail in such a manner. Also, when
> > > I
> > > use MD2 hashing algorithm with the same provider, I have not seen any
> > > problem
> > > either (including for the same password that has problems decrypting as
> > > mentioned above).
> > >
> > > Is it possible that there exist a problem with the Cryptography provider,
> > > or
> > > hashing alogrithm, or combination of the those two I am using? Thanks for
> > > any
> > > help.