Cryptographic Hash Functions

I saw an article where they suggested using the following algorithm:

• we take the password
• make hash (md5)
• break the hash with its function
• make the resulting hash

its function involves replacing letters in a hash by position in the original record of certain letters by others, for example:

a = @ s = $ o = 0 can still be added to replace the capital letter

initial password: password

hash: 5f4dcc3b5aa765d61d8327deb882cf99

broken hash: 5 @ $$ c03b5 @ $$ 60d61 @ $$ 20deB @ $$ c099

second hash: 212fee4334b1eea4911bea4051a61c7d

You can also not repeat the replacement and replace part of the word, as an option to start a replacement from the position = password length, use fantasy.

Dear Dex, it was necessary to immediately ask the question how to protect against theft of cookies. There is a popular scheme for this, using the same autologin is done on sites:

there is a table of approximately the same structure:

id | user_id | token1 | token2 

when the user logs in to the site (enters the login and password) you put a record in the table. token1 and token2 are some sort of random data hash (which hashing algorithm is not so important)

In cookies, these tokens are placed, for example, in this form: token1: token2 (or, knowing the length of the hash, you can not use the separator ":")

So, now the situation: User1 (the true owner of these cookies) returns to the site, we parse the cookie and see that for token1 and token2 there is such a record, let it go inside, at the same time! change the value of token2 to another random hash, both in the database and in the cookies themselves.

Now imagine that the attacker pulled our token1 and token2, naturally after visiting the site token2 has changed. After this, User1 comes to the site, we see that token1 is in our database, but token2 is different from what was expected, so we:

• delete this entry from the token table
• delete all active sessions of this user with token1

thus, cookies by the attacker become invalid. However, User1 must re-enter the password to get into the system.

If you say that you can change the password using cookies, then for this system you need to provide for changing the password with confirmation via email, the change of mail should also be with confirmation.

You can apply this method. We refuse cookies in general, but in each request we send a security token: hash(<пароль>+<URL страницы>+<текущая дата-время с точностью до минуты>) . For example, http://example.com/some/page?security=12345678 . It is clear that the server can verify the correctness of the token, since it knows the password. And the attacker cannot compose this token, since he does not know the password, and by intercepting an HTTP request, he will recognize the token for only one page, which is valid for a minute.

Of course, we do not want to force the user to calculate and drive a hash into the address bar. We can either create an absolutely dynamic Javascript website, which asks for a password at the beginning of the session, and then loads all pages with Ajax, secretly adding tokens to URLs. Or you can store the password in the local storage of the browser (LocalStorage), and add Javascript to each page, which rules all links after loading - then we can make a less dynamic website with real page reloads.

It is clear that this is all trash, but, as I understand it, you have a problem with some local site, for example, an enterprise site. In this case, the transformation of the site into a web application can probably be justified. If the site is public, then these perversions will not go unnoticed, and users will not love you for them.

The given scheme is quite safe, but only if we have read-only man-in-the-middle. But if he can edit the information transmitted from the server to the client, then everything is bad - he will simply replace his home page, which will not store the password locally, but send it directly to him. And nothing can be done with this, except for what has already been done in SSL, namely, server identification with the help of a certificate. Well, it is impossible to find out if the server is correct, whether the authorization page is correct (whether the salt was sent by the server, etc.), without agreeing with it about some general secret that can be checked, revealing this secret, or not agreeing with someone else, who agreed with the server. A secret that can be verified without opening it means using public key cryptography. A third party contract is the use of a third-party certification server whose certificate is preinstalled on the client system. These two things, by and large, make up the SSL protocol, so the best thing you can do is overcome your certain problem that prevents you from using SSL.

Better so md5 (pass. $ Salt) Salt, any value, not random.

Everyone knows that using the md5 hash algorithm is no longer a solution to all problems.

1. To everyone? Many do not know how MD5 works!
2. The solution to all problems is only death!

What kind of hashing algorithm (s) would you use when developing a web page.

When developing a web page, I would use an IDE.

or rather database design and authentication systems?

You can store the user's password in the database in the form of MD5 or use special language functions (in PHP you can use hash_hmac to encrypt the password with your favorite algorithm and salt)

PS You have a very incorrect question. I would correct it in your place.

PPS I didn’t understand what your problem is with MD5 with salt (for example, more than 8 characters are chosen long enough - for an average statistical service).