Replace hashing function with asymmetric cryptography when password authentication

Question

I would like to know if the following ideas are feasible:

Hash function is one-way function.

Generate public key from private key is irreversible(asymmetric cryptography).

User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> save public key(drop private key)

Password authentication:

User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> verify the public key with the saved one.

Based on that:

a.User or others can encrypt selected information(by using public key) that only user can decrypt it.

b.System administrator can generate a public/private key pair then both user and administrator can encrypt/decrypt selected information(by using Diffie–Hellman key exchange method).

I think that brute-force method(exhaustive attack method) can crack any password, and it is only a matter of time.It should be an another topic.

I am trying to prevent user information leak or rainbow table attack even if system being hacked.

I have searched and read the following information:

https://crypto.stackexchange.com/questions/9813/generate-elliptic-curve-private-key-from-user-passphrase

Handling user login using asymmetric cryptography

Asymmetric Cryptography as Hashing Function

Answer 1

... hash value(as ECC private key) -> generate public key from private key

You are assuming that an arbitrary key (output of a hash) can be used as an ECC private key and that the public key can be derived from this. This is not how it works though. If you want to derive a key pair from an existing random string or passphrase you would need to use some deterministic random generator in the key generation process - see How can one securely generate an asymmetric key pair from a short passphrase?.

If you see the conflict between the words deterministic and random in the last sentence you might realize that this is maybe not such a great idea to do. It should be doable though.

I'm pretty sure that there is a better way to solve the actual problem you have. But currently I see only particular technical aspects in your question and not a real description of the underlying problem you are trying to solve at the end, so it is hard to tell how a better approach to the (unknown) underlying problem would be. It might be useful though that you check (and document in your question) existing approaches to your problem in more detail first before determining that you need to invent your own approach - see Why shouldn't we roll our own?.

Answer 2

I am trying to prevent user information leak or rainbow table attack

To prevent usage of rainbow tables, it is sufficient to use random long salt, e.g. 128 bit salt.

One of the links you mentioned, Asymmetric Cryptography as Hashing Function explains well disadvantages of using asymmetric cryptography for password hashing. In particular, password verification can be much faster than compared to Argon2. Means, brute-forcing can be much easier compared to Argon2.

To make brute-forcing impossible, verification of each password needs to be expensive. The algorithms like Argon2 can be configured so that verification of a every single password requires much more CPU and RAM than fast algorithms like SHA1.

That's why I'd suggest you to consider Argon2. If it is not available for you (e.g. because your customer does not allow some algorithms), consider using bcrypt, scrypt, PBKDF2.

Update

Making an algorithm complex does not make it secure.

1. In the algorithm you use salt. But on the last step you only save the public key. This is not sufficient. You need to save also the salt, otherwise it will not be possible to verify passwords later on.

2. The only reason your algorithm is resistant to rainbow tables is the usage of salt (provided that you use it properly, i.e. you save the salt together with public key). If you remove salt, your algorithm will not be resistant to rainbow tables.

3. Your algorithm will be very fast. This means that brute-forcing your algorithm will be much easier for an attacker compared to properly configured password derivation algorithms like Argon2. Suppose checking of a single password with your algorithm takes 1 / 1 000 000 s and 1 K RAM. Suppose some other application uses Argon2 to hash password and hashing of a single password takes 1 s and 1 MB RAM. This means, to brute-force your database with hashed passwords an attacker will need 1 000 000 less CPU power and 1000 times less memory, means an attacker will need way less money and less time to brute-force your hashes compared to Argon2 hashes.

Despite brute-forcing of really random passwords will still be hard, it will make sense for an attacker to at least do a dictionary attack, i.e. some set of words and some common modifications of these words. Suppose an attacker takes 100 000 words and 1 000 000 modifications for each word. Thus there would be 10 000 000 000 passwords to test. If your check takes 1 / 1 000 000 s, this would take 100 000 s which is about 28 h on a single computer. If the attacker has money to rent 1 000 virtual machines for 10 days, then this will allow to test even more modifications of dictionary words. This means that at least dictionary attack may be successful.

What can you do? Use some password derivation algorithm that is resource expensive, e.g. Argon2. Configure it so that a single test takes 1 s and say 1 MB RAM on your server.