Username/Password authentication in Internet banking

Srinivas_Vengala
Srinivas_Vengala used Ask the Experts™
on
Can somebody tell me how a typical username/password authentication works in an Internet Banking application? How and where the passwords are stored at the bank end and more details about it? Any references to security diagrams that explains the username/password (single factor authentication) is much appreciated.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Every individual bank, fortunately has its OWN way of authenticating.  This has been necessary to STOP nosy people from tying to HACK internet banking logins.  They NEVER USE Cookies anymore -- their authentication is done ONLY on their OWN servers, and you will NEVER be able to crack their code.

That is the way it HAS to be.  There is NO WAY that banks can afford to do any authentication other than on their OWN servers, and the methods they use individually will NEVER be made public, NOT EVER !!!!!

Author

Commented:
I am just trying to understand/learn a banking application's environment. I have asked how a typical username/password authentication works. FYI, I am not a HACKER :).  
Hi  Srinivas, Please find below working mechanism for  username and password authentication. I  am  trying to explian you the  authentication  system if  you are agree and got it  please accept it.


Generally  banking apllication is  design in  2 -tier architecture means the  application  login and business logic is placed at different locations. There is a system for requiring a username/password before a client can visit a webpage. This is called authentication and is implemented on the server.

In the  internet banking the  Username and password are stored to the Database Server. when user login to the  system it  will check the whether the input entered by  the  client user is matching with  database according to  business logic.  If it is matching, then  user can  login to the  account.

Technically basic authentication goes like this :

    * client makes a request for a webpage
    * server responds with an error, requesting authentication
    * client retries request - with authentication details encoded in request
    * server checks details and sends the page requested, or another error
*Making a Request
A client is makes requests over the internet  browser  When a client asks for a web page, it is sending a request to a server. The request is made up of headers with information about the request. These are the 'http request headers'.

Getting A Response

When the request reaches the server it sends a response back. The request may still fail (the page may not be found for example), but the response will still contain headers from the server. These are 'http response headers'.
If there is a problem then this response will include an error code that describes the problem. You will already be familiar with some of these codes - 404 : Page not found, 500 : Internal Server Error, etc.

----------------------------------------------------------




Should you be charging more for IT Services?

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Sorry  by mistake I  have written  banking application is  design in  2 -tier architecture.  It  should be   3  tier architecture.

Author

Commented:
swapnilkude, thank you for your detailed explanation. Got your point.
So, the the password is stored in the database in an encrypted format. My actual question now is, so a developer of that banking application knows the encryption protocol used and he/she can decrypt the passwords in the database .. right? Or will there be a mechanism that prevents even the developer of the application or anyone else for that matter, from knowing the encryption protocol used?


@Srinivas_Vengala:  

Generally  developer use the encryption protocol / algorithm like or the  functions like 'cript()' to  store the  password in  database.

The best practices is used by  developer  to save the md5()'d password into the database, as this if someone were to crack the database, they wouldn't be able to use the passwords. Not even developer is  able to see what the passwords are.


Kindly requesting that, if u are  satisfied then please  accept the  solution.

Thanks
Swapnil
Hi Srinivas_Vengala,

Please find more abot the MD 5

MD5 encryption is a one-way hashing algorithm. Two important properties of the MD5 algorithm are that it is impossible to revert back an encrypted output to the initial, plain-text input, and that any given input always maps to the same encrypted value. This ensures that the passwords stored on the server cannot be deciphered by anyone. This way, even if an attacker gains reading permission to the user table, it will do him no good.

- Swapnil
hi, just a note about encrypting passwords

on most applications, it is just simply useless, and a fake idea of security

when you sniff a network and retrieve a password, the fact that it is encrypted does not really make a difference,
even if the encryption algorythm is military grade stuff

the only way such things are secure is by using a challenge-response mechanism
this is what hash functions are for

an example setting using md5 would be
- send a random large string to the client (and remember which client got which string)
- have a js script that builds the md5 of the concatenation of the password and that string
- on the server build the same calculation and compare with the velue in the database (extra encrypted or not, who cares)

actually most banks use such algorythms but hacked in their own way
actually mine makes use of a technique i developped years ago (should have sold them if i knew ;)
this is their implementation (which is pretty insecure in my opinion, btw)
- generate an image looking like a chess board with all 10 digits randomly distributed
obviously the image changes every time the logging page is called, and is actually random
- ask the user to click on the digits to type his pass number
- send the coordinates of the clicked places over the network, but not the code (which the js does not have either, btw)
- check the results, knowing which board you are answering to

they is much to say on the subject
just please do not rely on strong encryption when it is poorly implemented
and essentially understand that challenge-response and a proper anti brute-force attack code
are the basic keys to any reasonable security.
@Swapnil: "This way, even if an attacker gains reading permission to the user table, it will do him no good. "

That is not true, if I have the password hash then I can start doing an offline attack against it. That typically constitutes of running a brut forcer against it or using rainbow tables. Either way it is a matter of time before you can recover the unencrypted password (which can range from minutes to thousands of years).

@skullnobrains:
":hi, just a note about encrypting passwords

on most applications, it is just simply useless, and a fake idea of security"

I don't  agree at all. How is a password useless? If that was the case then EVERY web site on the internet would be easy to compromise. Can you explain this?

"when you sniff a network and retrieve a password, the fact that it is encrypted does not really make a difference,"

Again I don't agree. How does encryption NOT make a difference? Both statements go against every well known and common security concept so I'm not sure if you are implying something else entirely. Encryption is designed to prevent people from discovering the content of a message and prevent the modification of the message.

I do agree that the image validation is a security issue, and in some cases can bypass password security. Also, that a poor implementation of encryption can weaken security. I personally have not seen anyone implement the image validation in a way that improves security. I believe many banks did this as a way to adhere to the OCC/FFIEC policy requirement that was required in Nov/Dec of 2006?7?

"and essentially understand that challenge-response and a proper anti brute-force attack code are the basic keys to any reasonable security.                                                     "

What does do you mean by "anti-brute-force attack code"?


@Swapnil: As someone in application security who has worked in an international bank I'll give you some insight to my perspective.

1st - Why are you interested in bank security specifically? Your question does imply interest in breaking into a bank.

2nd - Online banking security is not much different (in general concepts) then any other online system. When you visit a online site you are issued a token, since the internet (HTTP) is not persistent, so the web site can know who you are. This token (cookie) allows you to go to all of the different pages on a site without having to re-login at every page. This cookie is just a string of characters (which can be several things, plain text, encrypted sensitive info, or just a random string) that has a clone that can be stored on the server in a database.

So, your question was "How and where the passwords are stored at the bank end and more details about it?"

When you login, your username and password are typically encrypted then compared to what is in the database. If the challenge/response passes then you are issued a token (cookie) that allows you to access the web site. The token that is on your computer is then referenced at every web page that would require you to login, so you don't have to. The token (cookie) is what handles your session management. So, there is no 'standard' way that banks specifically, or anyone else for that matter, handle logins but this concept is typically how it works anywhere.

And you can see that there is a lot of room for doing authentication your own way and I know each bank has it's own way as well.

> @skullnobrains:
> ":hi, just a note about encrypting passwords

> on most applications, it is just simply useless, and a fake idea of security"

> I don't  agree at all. How is a password useless? If that was the case then EVERY web site on the internet would be > easy to compromise. Can you explain this?

encrypting them during transfer is often useless. the passwords themselves are usefull

> "when you sniff a network and retrieve a password, the fact that it is encrypted does not really make a difference,"

> Again I don't agree. How does encryption NOT make a difference? Both statements go against every well known and common security concept so I'm not sure if you are implying something else entirely. Encryption is designed to prevent people from discovering the content of a message and prevent the modification of the message.

because if the password is sent encrypted with no challenge, sending the exact same encrypted password will let you in. basically if i sniff a network and see user "john" login with the password "sunshine" or with "jvrhklgrmk" standing for the encrypted form of sunshine in whatever algorythm, i can login using what i sniffed encrypted or not.

i believe you are well aware of that, but i guess my post was unclear

> I do agree that the image validation is a security issue, and in some cases can bypass password security. Also, that a poor implementation of encryption can weaken security. I personally have not seen anyone implement the image validation in a way that improves security. I believe many banks did this as a way to adhere to the OCC/FFIEC policy requirement that was required in Nov/Dec of 2006?7?

> "and essentially understand that challenge-response and a proper anti brute-force attack code are the basic keys to any reasonable security.                                                     "

> What does do you mean by "anti-brute-force attack code"?

detection and action can be implemented in varieties of ways

in many cases, simple blacklisting of the IP address and or deactivation of the account is enough.
other systems imply random password generation, throttling so you cannot try to login the same account more than once every few seconds, and change the password often enough to defeat brute-force attacks even if the attacker is reasonably lucky.
some including many banks use a challenge response system than can only be computed by a human
some well-thought such systems would imply severe blacklisting upon specific errors that a human cannot make, but that a bot would

i'll explain this last one with an example
let's say you send a canvas with letters, the user clicks the proper letters in turn, the navigator sends the coordinates back, and obviously the canvas changes (which is what my bank does).
a bot that does not implement a full navigator may send random coordinates until it gets through.
having a series of dead coordinates in each image, is a good ant brute-force complement.
a real user can type a wrong password, but not send dead coordinates, because the client-side javascript will not let him do it so you hardly ever blacklist a human, but a bot sending random coordinates will stumble into such traps almost instantaneously

@skullnobrains:

"encrypting them during transfer is often useless. the passwords themselves are usefull"

I still don't follow, can you provide an example?


"because if the password is sent encrypted with no challenge, sending the  exact same encrypted password will let you in. basically if i sniff a  network and see user "john" login with the password "sunshine" or with  "jvrhklgrmk" standing for the encrypted form of sunshine in whatever  algorythm, i can login using what i sniffed encrypted or not."

So you are talking about a replay attack here, correct? If so, SSL/TLS encryption provides the ability to prevent replay attacks.  The client and the server each provide part of the random data used to generate the keys for a connection. (The random portions of  the connection that initiate a session, drawn from both the client  and the server, are used to generate the master secret associated  with that session.) Additionally, each record is protected with a  MAC (Message Authentication Code) that contains a sequence number for  the message. So again I don't follow, can you provide another example proving your statement?


"i'll explain this last one with an example"

I'm not going to speculate on something that's theoretical and not being used by banks in the US (or, at least, anywhere that I know of) and since that does not address the authors question.





pand0ra_usa

i have to in general agree with you, there are so many mechanisms that have been put in place to ensure even the hashed string is only usable once, sometimes by embedding a random string as a salt string which is refreshed with every successful login.
 the overall string that is sent through including as you indicated the MAC is almost always not reusable (as in the case of a replay).

the only successful attack of user authentication was through a worm that attacked the client desktop, where it did keylogging on when the user got to a specific site, this information was then sent through to a site in russia and they then logged on with those accounts.

with the introduction of simple mechanisms such as pin numbers and then random subset's of the password it makes it all but impossible to determine what part of the password it is. additionally most banks are introducing token based otp technologies. which make it even more difficult to replay the password hashed or unhashed as it is never the same.

But great explanation,
I was the CSO for an international bank for about 8 years and what i can tell you now is that the attacks almost never happen on the site anymore but rather through fishing attacks or attacks on the desktops.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial