0

I'm a fan of SHA-512, because the hash remains the same.

I'm currently working on an open source keyboard listener, which takes insecure passwords, like:

  • 123456
  • qwerty
  • password

and secures them, by running them through a hashing algorithm, along with a private salt string unique to the user. Then replaces said insecure password with 20 characters from the hash string. Thus, making any password, secure.

Basically, you'd enter: @/password@/

and it would be replaced by: ajErqAR5fpe76YBnrHtA

I was using SHA512, but was told over at r/cryptography that I needed to switch to Argon2. I noticed that every time I'd use my program, I'd get different results in password fields. This isn't beneficial to login with, as the password must be the same every time it's entered.

I've modified my python code to:

def hash(entered_password, user_salt):
    return argon2.low_level.hash_secret(entered_password.encode(), user_salt.encode(), time_cost = 1, memory_cost = 512, parallelism=2, hash_len=20, type=argon2.low_level.Type.D).decode()[-20:]

This has given me the same passwords each time.

A lot of the sites I'm using for reference, say that the values here should be system dependent. I would eventually like to see this in cellphone keyboards. Argon is completely new to me.

My question is: Given my values, would an outputted hash be the same from 2 devices (a phone and a computer)? If not, I need to switch back to SHA512.

KI4JGT
  • 471
  • 2
  • 5
  • 13
  • Hashing passwords like `123456` or `qwerty` does not make those passwords more secure. Storing a password using a hash just provides a way to store them that prevents someone from determining what the original password was by reading what is stored on disk. The problem with a password like `123456` is that it is easily guessable. Storing that password as a hash does not make it any less guessable. – CryptoFool Mar 16 '22 at 05:03
  • @CryptoFool the password is hashed with a private salt string unique to the user. So, it's hash(password+my_private_string) – KI4JGT Mar 16 '22 at 05:05
  • 1
    Are you providing the new salted and hashed password to the user...that is, telling them to enter something else when they next log in rather than entering "123456"? If not...if the user is going to continue to enter "123456" whenever they log in, then how is that password made to be any less guessable because you're doing something more complicated with it to store it on disk? – CryptoFool Mar 16 '22 at 05:08
  • On first run, the program generates a random 20 character string and saves it in a file called, my.salt. Every time the program runs afterwards, it loads that string into memory. When you enter @/password@/, the outputted string is hash(inputted_password + my.salt) It isn't just a hash of the password. – KI4JGT Mar 16 '22 at 05:13
  • I need to be sure that I can transfer my.salt between devices, and still get the same output. Seeing as Argon2 uses different outputs, unless properly configured, I'm curious if it will provide the same outputs from device to device, or if I need to go back to SHA512. – KI4JGT Mar 16 '22 at 05:15
  • 1
    I understand what you're asking. My point is that you may be wasting your effort if you think you are somehow making a guessable password like `123456` more secure because you are storing it on disk in some fancy way. – CryptoFool Mar 16 '22 at 05:17
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/242967/discussion-between-ki4jgt-and-cryptofool). – KI4JGT Mar 16 '22 at 05:20

0 Answers0