Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a PostgreSQL database, I can see the following fields in a table (for a specific record):

User = administrator Password = "ceMv9Me6go"

Now the following are true:

  • The password length is not fixed, thus I'm leaning towards it being an encryption rather than a hash.
  • The actual password is "password"
  • Salt is unknown (if at all used)

What steps should I take to learn what algorithm might have been used? How could I break the cryptography (assuming it is cryptographically protected) to recover the master password?

share|improve this question
From the information you have given, I think the best advice you can give your customer is to switch applications. It is highly likely given the details you've provided that the password storage is not very secure. Makes you wonder what other mistakes the developers made. – mikeazo Nov 11 '13 at 1:44
Since you know one plaintext/ciphertext pair, here are a few questions that if I were trying to figure it out I would want to know. Is the ciphertext deterministic for a single user? Is it deterministic across multiple users? You say the lengths are not the same. Do same length passwords have same length corresponding "ciphertexts"? – mikeazo Nov 12 '13 at 3:22
Continued: is there an obvious block length? In other words, do the sizes of all ciphertexts have some common multiple (like 40 bits or 80 bits). If you can access many, many ciphertexts, what is the entropy? If the entropy isn't high, it might be an encoding scheme instead of encryption. – mikeazo Nov 12 '13 at 3:26
As mike suggested, try decoding with various schemes. The appearance of the characters makes me think it might be base64, so glue an == to the end and try decoding it with a tool. Is there anything in the resulting bytes that lead you to a conclusion? Is it the same number of bytes as the password itself? Does it XOR with other passwords to yield a common stream you can factor out? – John Deters Nov 12 '13 at 18:25
I took the liberty of rewriting the question into a more acceptable form, and voted to reopen. @mikeazo would you agree? – John Deters Nov 12 '13 at 21:43

The first thing I would want to know is if the encoding is deterministic. This should be easy to test. Change the password, but make it the same value. If the value in the DB doesn't change, then it is deterministic. Also try this for a few users. Give them all the same password and see if the DB entries are the same.

If so, you don't really even need to reverse the process. Just write down a DB password value to which you know the corresponding password. If the customer forgets the password, change the DB entry to the known value and they can get back in. If it is not deterministic you may still be able to do this.

From there, operating under the assumption that it is crypto, I would try to see how password length affects DB value length. Are all DB value lengths a multiple of some value? If so you might have your block length. There could be some encoding (base64) though, so that could play into it too.

To get an idea as to whether or not it is crypto protecting the DB you could test the entropy of a number of DB values.

If all else fails, reverse engineer the application.

share|improve this answer
Thanks Mike, appreciate the input; will test and see what happens. – Litch Nov 13 '13 at 3:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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