Coco FuxnBumz -
The use of such a small token such as a calculator tool for securing internet banking transactions has now become mandatory. Token has become an additional factor in the authentication is to prove that my friend is really legitimate users. There may be wondering how to work the token as used Internet banking site? How small tools such as calculators that can produce numbers that are also known by internet banking server, but the tool was not terbubung with the server. In this article I will explain how the token internet banking, and in the next article I will make a token-based software and a simple website that will simulate internet banking.
Authentication Method
Authentication aims to prove who the real friend, if my friend is really the person he claims to be my friend (who you claim to be). There are many ways to prove who mate. Authentication method can be seen in 3 categories of methods:
1. Something You Know
It is the most common authentication method. This method relying on the confidentiality of information, such as passwords and PINs are. This method assumes that no one knows it except my friend a secret.
2. Something You Have
This usually is an additional factor to create a more secure authentication. This method relies items are unique examples are magnetic card / smartcard, hardware tokens, USB tokens, and so on. This method assumes that no one has the goods except for a mate.
3. Something You Are
It is the most rare diapakai because of technology and the human factor as well. This method rely on the uniqueness of the body parts that are not my friend may have on others such as fingerprint, voice or retina prints. This method assumes that the body buddy like fingerprints and retina, is probably the same with others.
And what about the traditional authentication methods such as the signature on the stamp? Go to the category which means that of the three methods above? I do not think there is a match, so I added another one which is "Something You Can". This method assumes that no one else in the world who can do that other than my friend. Indeed, the signature authentication is built on the assumption that no one can write a signature unless buddy buddy. Despite the fact that there are people who can mimic the signature of a very good friend, but the knowledge facts signature on paper is still recognized as authentic evidence of who mate.
Two Factor Authentication
In critical and sensitive applications such as financial transactions, the authentication method is not enough. Hence the term 2FA (Two Factor Authentication) which is a system that uses 2 factor authentication (method) is different. Four authentication methods I described sebelunya can be combined to improve security, one example is the combination of "something you have" in the form of ATM card with "something you know" in the form of a PIN. This combination is a combination of the most widely used.
Still another example is when my friend shopping in the modern market and pay by card, unwittingly buddy has been using more than one factor of authentication. The first factor is "Something You Have" ie credit / debit cards buddy. The second factor is "Something You Know", when prompted to enter a PIN into the EDC. There may even be a third factor that is "Something You Can", When prompted to sign a memorandum of payment are printed EDC.
Internet banking is also using two factor authentication with a combination of "something you know" in the form of passwords and "something you have" a hardware token (or token KeyBCA Mandiri).
Incurred Password Token Internet Banking
In general, there are two modes of use of internet banking token:
1. Fashion Challenge / Response (C / R)
This is the mode most often used when trading. In this mode the server provides challenge in the form of a series of numbers. That number must be entered into the token machine to get an answer (response). Then the user enters the number that appears on tokennya into the form on the Internet banking site. Tokens will be issued a code different challenge though with the same code on a periodic basis depending on the time when the challenge put in a token.
2. Mode Self Generated (Response Only)
In this mode the server does not provide a challenge (challenge) of any kind. Token users can directly issue a series of numbers without having to enter the challenge. As the mode C / R, also issued a token code that periodically vary depending on the time when the token is required to produce a self-generated code.
Actually, the answer given by the token in either C / R and Self Generated (resopnse only) is nothing but the password as well. However, different from the password used to login pal, token generated password has limitations for security reasons, namely:
1. May only be used one time
This is called OTP (One Time Password). Once a password is used, the same password can no longer be used for the second time. This way there is no point intercepting the token generated password because the password can not be used again. However, if the password is in-intercept so it never gets to the server, the password is still worthwhile because in the eyes of the server, the password has not been used.
2. May only be used within a limited time span
Token generated password has a very limited life, probably between 3-6 minutes when the old expires, the password can not be used, although it has never been used. Later I will explain why the password token requires age, time is a very critical element in this system.
3. May only be used in the context of narrow
If the password / PIN is used for password-free login context, in the sense that it is armed with a password, my friend can do many things, ranging from the view balances, check transactions and so on. But the token generated password, can only be used in the context of narrow, for example a password that is used to charge the toll to the number 08123456789, can not be used to transfer funds.
Lack of context because a password is needed to make a transaction bound by the challenge from the server, so that the password can not be used for other transactions that require a different challenge code. For example, if the server is a challenge given the last 3 digits of the phone number (for transactions contents pulse), or 3 digits destination account number (for transfer transactions). Then the token generated password for the transaction to number 0812555111222 contents pulses, will be valid also for the transfer of money to the account transactions 155,887,723,120,222. Because it happened to both transactions require passwords bound by the same code challenge, namely 222 (taken from the last 3 digits).
Context is only valid when the password is generated in fashion C / R. Password generated in Self Generated mode, can be used in any transaction that does not require a password to the challenge code.
So it can be concluded that the issued token password is:
1. Always changing periodically
2. It has a short life
3. Can only be used 1 times
4. Divided into two types, namely:
* Password contextually bound by a code in a fashion challenge challenge / response.* Password-free context resulting in a mode of self-generated.
Authentication Process
Such as passwords in general, on condition that the authentication is successful is:
client sent password = password stored on the server
With security reasons rarely server stores user passwords in plain-text. Typically server stores user passwords in hashed form so it can be returned in the form of plain-text. So successful authentication requirements above can be interpreted as tally hash of the password sent by the client must be the same hash value stored in the server. See the picture below for better understanding.
courtesy of "www.unixwiz.net / TechTips / iguide-crypto-hashes.html"
courtesy of "www.unixwiz.net / TechTips / iguide-crypto-hashes.html"
Use of Salt
To avoid brute-force attack against the hash stored on the server, then the calculated value before the user's password hashnya, first add a random string called the salt. Consider the following example, if the user's password is "secret", the pre-calculated value hashnya, password salt be added first random string "81090273" so that the calculated values are hashnya "secret81090273" not "secret".
Note that MD5 ("secret81090273") is 894240dbe3d2b546c05a1a8e9e0df1bc while MD5 ("secret") is 5ebe2294ecd0e0f08eab7690d2a6ee69. If without the use of salt, the attacker gets the hash value 5ebe2294ecd0e0f08eab7690d2a6ee69 could use the technique brute force attack or rainbow table to get the value of the password in plain-text. One example of online MD5 database that can be used to crack md5 is http://gdataonline.com/seekhash.php. In these sites try entering 5ebe2294ecd0e0f08eab7690d2a6ee69 value, then the site will result in "secret". This is because the site has been storing mapping information secret <=> 5ebe2294ecd0e0f08eab7690d2a6ee69.
The addition of salt "81090273" make a hash value 894240dbe3d2b546c05a1a8e9e0df1bc. If this value is included in the site, guaranteed not to exist in the database that the hash value is "secret81090273". And because the salt value is generated randomly, then each user has a different salt value that the attacker may not be able to build a database mapping between the plaintext and the hash is complete.
With the use of salt, then the user database in the server will look like this:
Salt Username Password Hash
81090273 favor 894240dbe3d2b546c05a1a8e9e0df1bc
Field salt is needed when authenticating. Password supplied by the user will be added once the salt value is then calculated value hashnya. Hash value calculation results will be compared with the Password Hash field in the column next to it. If the same, then the authentication is successful, if not the same, then the authentication fails. In principle, the same as the picture above, just added a step is the addition of salt before the calculated value hashnya.
Generation One Time Password (OTP) Token Internet Banking
What I have described previously the basis of what I will describe below. How to generate a series of numbers as the token OTP that can be authenticated by the server? Remember that the condition for successful authentication is the password sent by the client must be the same that is stored on the server. Remember also that the generated password token always changing periodically. How is what produced the device can be synchronized with the server? Though the device is not connected to the server, how can the server know how the value generated token? The answer is time. Earlier I mentioned that time is a very important element in this system. The server and the token can be synchronized by using time as a reference value.
OTP Mode Self Generated (Response Only)
I will explain the start of the OTP generation in self-generated or response mode only. Formerly, of course, the server and the token must agree to a secret initial value (init-secret). The initial value is stored (planted) in the token and also stored in the table on the server.
When at a certain time required generate OTP token without challenge code, this is what made token:
1. Taking the current time in seconds EPOCH format (number of seconds since January 1, 1970), usually within 10 seconds granularity, so the EPOCH value divided by 10.
2. Combining init-secret with the current time from step 1.
3. Compute the hash value init-secret combination and timing of step 2.
Hash value from step 3 is at the OTP. But the OTP is usually taken from some of the characters / digits at the beginning of the hash.
How to perform server authentication? The trick is similar to that of the token, ie by calculating the hash value of init-secret combination with the current time and take a few digits at the beginning of the OTP. If the OTP is sent the same user OTP server obtained from the calculation of the hash, then the authentication is successful.
However, there are few records that must be considered relevant time. To tolerate the time difference between the token and the server, as well as the lag time from the time server until the user asks for a password generating token request token, the server must provide tolerance time.
There are three events to note the time, namely:
1. Seconds when the server asks for a password (OTP) of the user
2. OTP tokens generate a second when
3. Seconds when it receives the OTP from the user
Consider the example below:
Assuming the exact same time with a time server on the token (token internal clock), then we should note that there will be a lag between events 1, 2 and 3. When the second-to-0 server asks for a password from the user, because of the slow internet access, it could be a new user 30 seconds to look at the browser that he must enter the OTP from the token. Later in the 60th minute to generate OTP token. In the second-to-65 user submits the OTP value to the server and the new server arrives at the second-to-90.
Due to the time-dependent generation of OTP OTP when raised, then the resulting OTP tokens, OTP was the second-to-60. While the server asks for a password from the user since the second-to-0. How to perform server authentication? The trick is to examine all possible OTP in the timeframe that is deemed adequate, say 180 seconds.
If the system uses granularity 10 seconds then the server must calculate the value of the second OTP since the 0, 10, 20, 30, 40, s / d to 180 in increments of 10 seconds. Consider the example in the figure below. In this system it is assumed OTP is 6 characters beginning of MD5 combined. In doing authentication, the server should compare all the values from the second to the OTP-0 (in this example EPOCH/10 = 124 868 042) to a maximum tolerance.
otptoken1Dalam the example above, if the user sends the OTP "b1cdb9" then authentication will be successful when the server calculates the value of the second OTP-60 from the server to the OTP requested from the user.
The illustration above is only an example, in fact there is the possibility of time between the server and the token is not exactly 100%, so the server is forced to tolerate the time not only forward, but also backwards. Because it could be the time at the server is faster than the time on the token. For example, when the time on the server shows EPOCH/10 = 124 868 219, it could be time in the new token shows EPOCH/10 = 1248682121 (a token fee 80 seconds).
Suppose the tolerance time is 3 minutes, then the server must tolerate the next 3 minutes and 3 minutes to the rear relative to the time when it receives the OTP from the user and authentication. Remember, when tolerance is relative to the time server authentication. So if a server to authenticate against the EPOCH/10 = 600, then the server must calculate the entire value of OTP since EPOCH/10 EPOCH/10 = 420 to = 780.
Remember my explanation of salt before. When compared with this OTP, the init-secret value is similar to the plain-text passwords of users, while the salt or enhancements is the time (EPOCH/10).
Age OTP
Earlier I mentioned that the nature of the OTP is to have a limited lifespan. Age is associated with a given server tolerance for X seconds forward and backward X seconds relative to the time server authentication. If a tolerance is 3 minutes (180 seconds), then the age of an OTP is 3 minutes, in a sense when server authentication is not more than 3 minutes since raised OTP token, the OTP will be considered valid by the server.
OTP in Fashion Challenge / Response
Generation and OTP authentication mode C / R is actually similar to the self-generated. When in a mode of self-generated additional (salt) from the init-secret is the time (EPOCH/10), the mode C / R is salt / enhancements more. Init-secret not only coupled with time, but also coupled with the challenge.
Note the picture below. OTP Server performs calculations for all seconds within tolerance.
otptoken2
In mode C / R there is an additional field to be joined before the calculated value hashnya, the challenge. Challenge value is known by the server, and also by the token (when users type challenge to the token), so that both the token and the server will be able to count so that the same OTP authentication process can take place.
Source: X-Code Community
The use of such a small token such as a calculator tool for securing internet banking transactions has now become mandatory. Token has become an additional factor in the authentication is to prove that my friend is really legitimate users. There may be wondering how to work the token as used Internet banking site? How small tools such as calculators that can produce numbers that are also known by internet banking server, but the tool was not terbubung with the server. In this article I will explain how the token internet banking, and in the next article I will make a token-based software and a simple website that will simulate internet banking.
Authentication Method
Authentication aims to prove who the real friend, if my friend is really the person he claims to be my friend (who you claim to be). There are many ways to prove who mate. Authentication method can be seen in 3 categories of methods:
1. Something You Know
It is the most common authentication method. This method relying on the confidentiality of information, such as passwords and PINs are. This method assumes that no one knows it except my friend a secret.
2. Something You Have
This usually is an additional factor to create a more secure authentication. This method relies items are unique examples are magnetic card / smartcard, hardware tokens, USB tokens, and so on. This method assumes that no one has the goods except for a mate.
3. Something You Are
It is the most rare diapakai because of technology and the human factor as well. This method rely on the uniqueness of the body parts that are not my friend may have on others such as fingerprint, voice or retina prints. This method assumes that the body buddy like fingerprints and retina, is probably the same with others.
And what about the traditional authentication methods such as the signature on the stamp? Go to the category which means that of the three methods above? I do not think there is a match, so I added another one which is "Something You Can". This method assumes that no one else in the world who can do that other than my friend. Indeed, the signature authentication is built on the assumption that no one can write a signature unless buddy buddy. Despite the fact that there are people who can mimic the signature of a very good friend, but the knowledge facts signature on paper is still recognized as authentic evidence of who mate.
Two Factor Authentication
In critical and sensitive applications such as financial transactions, the authentication method is not enough. Hence the term 2FA (Two Factor Authentication) which is a system that uses 2 factor authentication (method) is different. Four authentication methods I described sebelunya can be combined to improve security, one example is the combination of "something you have" in the form of ATM card with "something you know" in the form of a PIN. This combination is a combination of the most widely used.
Still another example is when my friend shopping in the modern market and pay by card, unwittingly buddy has been using more than one factor of authentication. The first factor is "Something You Have" ie credit / debit cards buddy. The second factor is "Something You Know", when prompted to enter a PIN into the EDC. There may even be a third factor that is "Something You Can", When prompted to sign a memorandum of payment are printed EDC.
Internet banking is also using two factor authentication with a combination of "something you know" in the form of passwords and "something you have" a hardware token (or token KeyBCA Mandiri).
Incurred Password Token Internet Banking
In general, there are two modes of use of internet banking token:
1. Fashion Challenge / Response (C / R)
This is the mode most often used when trading. In this mode the server provides challenge in the form of a series of numbers. That number must be entered into the token machine to get an answer (response). Then the user enters the number that appears on tokennya into the form on the Internet banking site. Tokens will be issued a code different challenge though with the same code on a periodic basis depending on the time when the challenge put in a token.
2. Mode Self Generated (Response Only)
In this mode the server does not provide a challenge (challenge) of any kind. Token users can directly issue a series of numbers without having to enter the challenge. As the mode C / R, also issued a token code that periodically vary depending on the time when the token is required to produce a self-generated code.
Actually, the answer given by the token in either C / R and Self Generated (resopnse only) is nothing but the password as well. However, different from the password used to login pal, token generated password has limitations for security reasons, namely:
1. May only be used one time
This is called OTP (One Time Password). Once a password is used, the same password can no longer be used for the second time. This way there is no point intercepting the token generated password because the password can not be used again. However, if the password is in-intercept so it never gets to the server, the password is still worthwhile because in the eyes of the server, the password has not been used.
2. May only be used within a limited time span
Token generated password has a very limited life, probably between 3-6 minutes when the old expires, the password can not be used, although it has never been used. Later I will explain why the password token requires age, time is a very critical element in this system.
3. May only be used in the context of narrow
If the password / PIN is used for password-free login context, in the sense that it is armed with a password, my friend can do many things, ranging from the view balances, check transactions and so on. But the token generated password, can only be used in the context of narrow, for example a password that is used to charge the toll to the number 08123456789, can not be used to transfer funds.
Lack of context because a password is needed to make a transaction bound by the challenge from the server, so that the password can not be used for other transactions that require a different challenge code. For example, if the server is a challenge given the last 3 digits of the phone number (for transactions contents pulse), or 3 digits destination account number (for transfer transactions). Then the token generated password for the transaction to number 0812555111222 contents pulses, will be valid also for the transfer of money to the account transactions 155,887,723,120,222. Because it happened to both transactions require passwords bound by the same code challenge, namely 222 (taken from the last 3 digits).
Context is only valid when the password is generated in fashion C / R. Password generated in Self Generated mode, can be used in any transaction that does not require a password to the challenge code.
So it can be concluded that the issued token password is:
1. Always changing periodically
2. It has a short life
3. Can only be used 1 times
4. Divided into two types, namely:
* Password contextually bound by a code in a fashion challenge challenge / response.* Password-free context resulting in a mode of self-generated.
Authentication Process
Such as passwords in general, on condition that the authentication is successful is:
client sent password = password stored on the server
With security reasons rarely server stores user passwords in plain-text. Typically server stores user passwords in hashed form so it can be returned in the form of plain-text. So successful authentication requirements above can be interpreted as tally hash of the password sent by the client must be the same hash value stored in the server. See the picture below for better understanding.
courtesy of "www.unixwiz.net / TechTips / iguide-crypto-hashes.html"
courtesy of "www.unixwiz.net / TechTips / iguide-crypto-hashes.html"
Use of Salt
To avoid brute-force attack against the hash stored on the server, then the calculated value before the user's password hashnya, first add a random string called the salt. Consider the following example, if the user's password is "secret", the pre-calculated value hashnya, password salt be added first random string "81090273" so that the calculated values are hashnya "secret81090273" not "secret".
Note that MD5 ("secret81090273") is 894240dbe3d2b546c05a1a8e9e0df1bc while MD5 ("secret") is 5ebe2294ecd0e0f08eab7690d2a6ee69. If without the use of salt, the attacker gets the hash value 5ebe2294ecd0e0f08eab7690d2a6ee69 could use the technique brute force attack or rainbow table to get the value of the password in plain-text. One example of online MD5 database that can be used to crack md5 is http://gdataonline.com/seekhash.php. In these sites try entering 5ebe2294ecd0e0f08eab7690d2a6ee69 value, then the site will result in "secret". This is because the site has been storing mapping information secret <=> 5ebe2294ecd0e0f08eab7690d2a6ee69.
The addition of salt "81090273" make a hash value 894240dbe3d2b546c05a1a8e9e0df1bc. If this value is included in the site, guaranteed not to exist in the database that the hash value is "secret81090273". And because the salt value is generated randomly, then each user has a different salt value that the attacker may not be able to build a database mapping between the plaintext and the hash is complete.
With the use of salt, then the user database in the server will look like this:
Salt Username Password Hash
81090273 favor 894240dbe3d2b546c05a1a8e9e0df1bc
Field salt is needed when authenticating. Password supplied by the user will be added once the salt value is then calculated value hashnya. Hash value calculation results will be compared with the Password Hash field in the column next to it. If the same, then the authentication is successful, if not the same, then the authentication fails. In principle, the same as the picture above, just added a step is the addition of salt before the calculated value hashnya.
Generation One Time Password (OTP) Token Internet Banking
What I have described previously the basis of what I will describe below. How to generate a series of numbers as the token OTP that can be authenticated by the server? Remember that the condition for successful authentication is the password sent by the client must be the same that is stored on the server. Remember also that the generated password token always changing periodically. How is what produced the device can be synchronized with the server? Though the device is not connected to the server, how can the server know how the value generated token? The answer is time. Earlier I mentioned that time is a very important element in this system. The server and the token can be synchronized by using time as a reference value.
OTP Mode Self Generated (Response Only)
I will explain the start of the OTP generation in self-generated or response mode only. Formerly, of course, the server and the token must agree to a secret initial value (init-secret). The initial value is stored (planted) in the token and also stored in the table on the server.
When at a certain time required generate OTP token without challenge code, this is what made token:
1. Taking the current time in seconds EPOCH format (number of seconds since January 1, 1970), usually within 10 seconds granularity, so the EPOCH value divided by 10.
2. Combining init-secret with the current time from step 1.
3. Compute the hash value init-secret combination and timing of step 2.
Hash value from step 3 is at the OTP. But the OTP is usually taken from some of the characters / digits at the beginning of the hash.
How to perform server authentication? The trick is similar to that of the token, ie by calculating the hash value of init-secret combination with the current time and take a few digits at the beginning of the OTP. If the OTP is sent the same user OTP server obtained from the calculation of the hash, then the authentication is successful.
However, there are few records that must be considered relevant time. To tolerate the time difference between the token and the server, as well as the lag time from the time server until the user asks for a password generating token request token, the server must provide tolerance time.
There are three events to note the time, namely:
1. Seconds when the server asks for a password (OTP) of the user
2. OTP tokens generate a second when
3. Seconds when it receives the OTP from the user
Consider the example below:
Assuming the exact same time with a time server on the token (token internal clock), then we should note that there will be a lag between events 1, 2 and 3. When the second-to-0 server asks for a password from the user, because of the slow internet access, it could be a new user 30 seconds to look at the browser that he must enter the OTP from the token. Later in the 60th minute to generate OTP token. In the second-to-65 user submits the OTP value to the server and the new server arrives at the second-to-90.
Due to the time-dependent generation of OTP OTP when raised, then the resulting OTP tokens, OTP was the second-to-60. While the server asks for a password from the user since the second-to-0. How to perform server authentication? The trick is to examine all possible OTP in the timeframe that is deemed adequate, say 180 seconds.
If the system uses granularity 10 seconds then the server must calculate the value of the second OTP since the 0, 10, 20, 30, 40, s / d to 180 in increments of 10 seconds. Consider the example in the figure below. In this system it is assumed OTP is 6 characters beginning of MD5 combined. In doing authentication, the server should compare all the values from the second to the OTP-0 (in this example EPOCH/10 = 124 868 042) to a maximum tolerance.
otptoken1Dalam the example above, if the user sends the OTP "b1cdb9" then authentication will be successful when the server calculates the value of the second OTP-60 from the server to the OTP requested from the user.
The illustration above is only an example, in fact there is the possibility of time between the server and the token is not exactly 100%, so the server is forced to tolerate the time not only forward, but also backwards. Because it could be the time at the server is faster than the time on the token. For example, when the time on the server shows EPOCH/10 = 124 868 219, it could be time in the new token shows EPOCH/10 = 1248682121 (a token fee 80 seconds).
Suppose the tolerance time is 3 minutes, then the server must tolerate the next 3 minutes and 3 minutes to the rear relative to the time when it receives the OTP from the user and authentication. Remember, when tolerance is relative to the time server authentication. So if a server to authenticate against the EPOCH/10 = 600, then the server must calculate the entire value of OTP since EPOCH/10 EPOCH/10 = 420 to = 780.
Remember my explanation of salt before. When compared with this OTP, the init-secret value is similar to the plain-text passwords of users, while the salt or enhancements is the time (EPOCH/10).
Age OTP
Earlier I mentioned that the nature of the OTP is to have a limited lifespan. Age is associated with a given server tolerance for X seconds forward and backward X seconds relative to the time server authentication. If a tolerance is 3 minutes (180 seconds), then the age of an OTP is 3 minutes, in a sense when server authentication is not more than 3 minutes since raised OTP token, the OTP will be considered valid by the server.
OTP in Fashion Challenge / Response
Generation and OTP authentication mode C / R is actually similar to the self-generated. When in a mode of self-generated additional (salt) from the init-secret is the time (EPOCH/10), the mode C / R is salt / enhancements more. Init-secret not only coupled with time, but also coupled with the challenge.
Note the picture below. OTP Server performs calculations for all seconds within tolerance.
otptoken2
In mode C / R there is an additional field to be joined before the calculated value hashnya, the challenge. Challenge value is known by the server, and also by the token (when users type challenge to the token), so that both the token and the server will be able to count so that the same OTP authentication process can take place.
Source: X-Code Community
0 komentar:
Posting Komentar