Understanding How it Works Token net Banking (3)

Authentication process

Such as passwords generally, on condition that the authentication is successful are:

client sent password = password stored on the server

With security reasons rarely server stores user passwords in plain-text. generally server stores user passwords in hashed type so it can not be came in the kind of plain-text. So, the authentication is successful the on top of conditions are often interpreted because the results of calculating the hash of the password sent by the consumer must be equal to the hash price stored in the server. Note the image below for better understanding.

Use of Salt

To avoid brute-force attack against the hash that’s stored on the server, then the calculated price before the user’s password hashnya, first add a random string called the salt. take into account the subsequent example, if the user’s password is “secret”, then before the calculated price hashnya, password salt was added in the kind of a random string “81090273″ in order that the calculated price hashnya is “secret81090273″ instead of “secret”.

Note that the MD5 price (“secret81090273″) is 894240dbe3d2b546c05a1a8e9e0df1bc whereas the worth of MD5 (“secret”) is 5ebe2294ecd0e0f08eab7690d2a6ee69. If while not the use of salt, an attacker who can get the hash price using a technique 5ebe2294ecd0e0f08eab7690d2a6ee69 brute force attack or rainbow table to get the worth in plain-text passwords. One example of a web database of MD5 which will be used to crack md5 is http://gdataonline.com/seekhash.php. In making an attempt to enter the site 5ebe2294ecd0e0f08eab7690d2a6ee69 price, then the site will deliver results “secret”. this can be because the site has been storing the mapping information secret <=> 5ebe2294ecd0e0f08eab7690d2a6ee69.

The addition of salt “81090273″ to make a 894240dbe3d2b546c05a1a8e9e0df1bc hash price. If this price is included in the website, guaranteed to not exist in the database that the hash price is “secret81090273″. and since the salt is generated randomly, then each user features a different salt price that’s unimaginable attacker can build a database mapping between the plaintext and hash in full.

With the use of salt, then the user database in the server will seem like this:

Username: mind

Salt: 81090273

Password Hash: 894240dbe3d2b546c05a1a8e9e0df1bc

Salt field is required when performing authentication. Password is distributed once a user is added with this salt price and then calculated the worth hashnya. The hash price calculation results are going to be compared with Password Hash field in the column next to it. If equal, then the authentication is successful, if not a similar, it means the authentication failed. In principle a similar because the picture on top of, just one step is added before the addition of salt hashnya calculated price.

Generation one time Password (OTP) Token web Banking

What I described earlier type the idea of what I describe below. the way to generate a series of numbers as a token OTP which will be authenticated by the server? keep in mind that the condition that the authentication is successful is that the password that’s sent the consumer should be equal to that stored on the server. keep in mind additionally that the token generated password is often changing periodically. How is what generated the device can sync with the server? Though the device is not connected to the server, how can the server savvy the worth of the ensuing token? the solution is with time. Earlier i mentioned that time could be a very important element during this system. Server and tokens are often synchronized by using time as a reference price.