1
votes

I'm going to use this kind of approach to store my password:

  1. User enters password
  2. Application salts password with random number
  3. Then with salted password encrypt with some encryption algorithm randomly selected array of data (consisting from predefined table of chars/bytes)
    • for simplicity it can be used just table of digits, so in case of digits random array would be simply be long enough integer/biginteger.
  4. Then I store in DB salt (modified value) and encrypted array

To check password validity:

  1. Getting given password
  2. Read salt from DB and calculate decrypt key
  3. Try to decrypt encrypted array
  4. If successfull (in mathematical mean) compare decrypted value byte by byte
    • does it contains only chars/bytes from known table. For instance is it integer/biginteger? If so - password counts as valid

What do you think about this procedure?

In a few words, it's a kind of alternative to using hash functions...

In this approach encryption algorithm is about to be used for calculation of non-inversible value.

EDIT

# Encrypt/decrypt function that works like this:
KEY=HASH(PASSWORD)
CYPHERTEXT = ENCRYPT(PLAINTEXT, KEY)
PLAINTEXT = DECRYPT(CYPHERTEXT, KEY)

# Encrypting the password when entered
KEY=HASH(PASSWORD)+SALT or HASH(PASSWORD+SALT)
ARRAY={A1, A2,... AI}
SOME_TABLE=RANDOM({ARRAY})
ENCRYPTED_TABLE = ENCRYPT(SOME_TABLE, KEY + SALT)

# Checking validity
DECRYPT(ENCRYPTED_TABLE, PASSWORD + SALT) == SOME_TABLE
if(SOME_TABLE contains only {ARRAY} elements) = VALID
else INVALID
3
Why? What's wrong with using a hash function + salt?Graeme Perrow
Nothing wrong... Just trying to invent wheel :)Barmaley

3 Answers

1
votes

The proposed scheme is, at best, slightly less secure than simply storing the hash of the password and salt.

This is because the encryption step simply adds a small constant amount of time to checking if each hash value is correct; but at the same time it also introduces classes of equivalent hashes, since there are multiple possible permutations of ARRAY that will be recognised as valid.

2
votes

From what you write I assume you want to do the following:

# You have some encryption function that works like this
CYPHERTEXT = ENCRYPT(PLAINTEXT, KEY)
PLAINTEXT = DECRYPT(CYPHERTEXT, KEY)

# Encrypting the password when entered
ENCRYPTED_TABLE = ENCRYPT(SOME_TABLE, PASSWORD + SALT)

# Checking validity
DECRYPT(ENCRYPTED_TABLE, PASSWORD + SALT) == SOME_TABLE

First off: No sane person would use such a homemade scheme in a production system. So if you were thinking about actually implementing this in the real world, please go back. Don't even try to write the code yourself, use a proven software library that implements widely accepted algorithms.

Now, if you want to think about it as a mental exercise, you could start off like this:

If you should assume that an attacker will know all the parts of the equation, except the actual password. The attacker, who wants to retrieve the password, will therefore already know the encrypted text, the plaintext AND part of the password.

The chance of success will depend on the actual encryption scheme, and maybe the chaining mode.

I'm not a cryptanalyst myself, but without thinking about it too much I have the feeling that there could be a number of angles of attack.

0
votes

You would have to brute force the encryption on every password every time someone logs in.

Read salt from DB and calculate decrypt key

This can't be done unless you know what the password is before hand.

Just salt (And multiple hash) the password.