Creating function to encrypt password

I currently have a script that encrypts my password.
In this way.

#/bin/bash
PASSWORD="test123"
MD5=`echo $PASSWORD | openssl passwd -1 -stdin`

Result:

$1$xlmxNekA$1QN3C.WgbrAmbQvhKGIxx/

Can I convert this to a function in the elixir?

If so, how do I do it?

As I already have an application running in production, with this authentication method.
I cannot change, to another method.

It is not encryption, this is hash. And you should not use this method (which is crypt method from the Unix) as it is highly unsafe way. If you want something secure, then check Comeonin with Argon or Bcrypt functions.

3 Likes

thanks for the feedback, however as i said.

I cannot change the authentication method.
because it is already in production.

If this is already in prod, please think of a way to migrate the data to a more secure system, for example by using user logins to upgrade the hash to a secure version. The current scheme endangers your users.

8 Likes

To underline what others have said, here is why using MD5 to hash passwords (especially without a salt) is a bad idea:

https://www.md5online.org/blog/why-md5-is-not-safe/

If you’re wondering how to migrate to a new hashing algorithm, this StackOverflow question has some useful pointers:

2 Likes

While I agree with all the previous posts regarding the security of md5crypt, the OP did indicate that this is for compatibility with an existing implementation. Migrating to something better still requires an implementation of the legacy algorithm.

Here’s something that should do the trick:

5 Likes

That only applies to weak passwords. With strong passwords brute force attacks and dictionary attacks are impossible.

1 Like

Still a better hashing algorithm let’s you not need to make that distinction in the first place. Using md5 for passwords has been a discouraged practice for many years by now.

1 Like

That’s a bit like saying “if you drive carefully you don’t need seatbelts”. Even if it’s technically correct why take the risk at all, especially when more secure alternatives are so readily available?

2 Likes

This is not true. With a collision attack (you can find collisions for MD5 in a matter of seconds on modern consumer hardware) knowing the MD5 hash gives you access to the user account.

That is completely incorrect. Collision attack has nothing to do with known MD5 hash or getting access to user account.

Preimage attack would be needed to make MD5 vulnerable in those cases, not collision attack. And MD5 is quite safe against preimage attack (2^123.4 complexity).

Here you would need preimage attack, but still using MD5 is poor solution. TBH using any general purpose hash function for storing passwords is poor solution, as these can be easily implemented in FPGA, which mean that just searching for collisions can be made fast, which is undesirable. That is why we have separate set of KDFs to compute the hashes of the passwords - to make such functions memory-dependant.

1 Like

If I log in with a wrong password that has the same hash value as the (unknown) correct password then I get access to the account. How is this incorrect? The server hashes the password and compares it to the stored hash. So if you can compute a hash collision, your user accounts are unprotected to anyone that has access to the hashed passwords (for example your staff).

Edit:
You are right, the correct term is preimage attack which is notably more difficult to do than a collision attack. I confused the two attacks.

I just realized that I have long overestimated the risks of MD5 for non-user-generated long passwords :smile: It is always good to post on this forum even if it is rubish as you can learn alot from the experts here : )

1 Like