AES encrypted passwords

[Alan DeKok]

On Sep 29, 2016, at 12:13 PM, Dom Latter <freeradius-users at latter.org> wrote:
> 
> some of you may remember me from a couple of months back asking
> about NTLM hashed passwords.  I gave those a brief go but found
> that some devices just didn't work with them.

  What does that mean?

  There is no "device" compatibility issues with NT hashed passwords.  Only incompatibility with password hashing schemes.

  See http://deployingradius.com/documents/protocols/compatibility.html

  for more details.

> The requirement - a commercial and marketing requirement, not a
> technical one - has not gone away and it is that we can say that
> we do not store the passwords in plain text.

  See the compatibility page.  You don't rally have a choice in some cases.

  When marketing requirements try to over-ride technical limitations, that doesn't work very well.

> I have concocted a scheme whereby we do that - the following goes
> into dialup.conf and is I hope self-explanatory:
> 
> authorize_check_query = "SELECT id, username, attribute, value, op \
> FROM ${authcheck_table} \
> WHERE username = '%{SQL-User-Name}' \
> AND attribute != 'AES-Password' \
> UNION \
> SELECT id, username, 'User-Password', \
>  AES_DECRYPT(UNHEX(value), 'aeskey'), op \
> FROM radcheck \
> WHERE username = '%{SQL-User-Name}' \
> AND attribute = 'AES-Password' \
> ORDER BY id"

  I guess that will work.  Tho it's not any more secure than just storing clear-text passwords in SQL.

  If you want security, store the encrypted passwords in SQL, and then decrypt them on the RADIUS server.  That way the SQL database has the passwords but not the decryption key, and the RADIUS server has the decryption key but not the password.

> We replace User-Password with AES-Password, decrypt it in the sql query

  Which means you're still passing the key to the SQL server.

> and pass it back to radius /as/ User-Password.  (Or Cleartext-Password
> is more likely in the final implementation).

  It's a hack which adds complexity, and no real security.

> Yes, the key is now held in /etc/freeradius and if someone gets that
> as well as the database then it's much the same as storing the passwords
> in plain text.  But we can *say* that they are stored encrypted - and
> there may be a slight edge in security, as a file in /etc/ *may* be
> less vulnerable than a mysql database.
> 
> Any thoughts on this scheme?

  It "works", just like putting a Ferrari sticker on your car "works".  But it doesn't add any real security.  And your car still isn't a Ferrari.

  Alan DeKok.