Not in practice. You are assuming that tries can be tested as fast as they can be generated and unlimited tries can be made. Neither of these conditions are true.
If you can get a response in a second it will take decades to have a fair chance of guessing the right one.
Most banks and other secure systems have a limit to your tries, usually three strikes and your’re out.
So just how would a brute force attack be carried out on a bank account in practice?
Mine is quite long and involves more than letters and numbers. It is changed regularly. I would not be happy with such a flimsy passphrase and I would have walked away from them, for many though they don’t realise the risks or they cannot sever their relationship. You and I do know what helps make secure passphrases but why does the Bank insist on such poor protection of their clients? Indeed “Words escape” perhaps even “beggars belief” or even usage of stronger words of condemnation (but not used here for the sake of polite conversation).
With multiple Virtual machines or a Bot network it can be a series of multiple tries each with a slightly different but close enough IP. A Bank should be looking for these traps but using such a poor “password” would call into question their security.
How does that test millions of passwords on an account?
That does not compute. A logon with the associated password is tested. Does not matter where it comes from or talk of “bots”. The logon attempt goes through the logon process. Good logon processes will only allow a limited number of attempts before the acount is either temporarily locked out for say an hour, or permanently locked out and you call the service.
In that sort of logon process it makes absolutely no difference whether the password is 6 characters or 20. Brute force guessing is useless.
I likely do use that bank or it’s cousin. My pass phrase is longer, the 6 characters being a minimum!
Some do make it easy to remember to suit the target clients.
I’ve also over many years regular use, twice been locked out after more than 3 failed attempts. It can take several seconds or longer for each rejection to reset. I’d assume they have other security traps for repeated attempts beyond the 3. I know mine has, but will not share that detail.
We also now use a RAS key, although some banks are now keen to use a mobile SMS, as does MyGov to log in. Unfortunately many mobiles by default display same as a notification even when the device is locked!
No system is perfect. I would be more concerned about what procedures a bank or financial institution might use (or not use) to verify details when updating or resetting account access?
So I thought, until I tried to enter the 7th and the form stopped accepting more 
I had a word already and predictably they extolled the virtues of their 2FA, guarantees, blah blah blah, but accepted the complaint.
If requests are made simultaneously they may bypass the “count” system, then waiting a little bit they can retry. Most successful attempts are made because passwords have been compromised in some way but Banks have been subjected to brute force attacks in the past and that is why I said Banks should be looking for that sort of attempt. It would be hoped they have security in place but there remains very limited disclosure here in Australia of the attempts or successes of such attacks.
My 14 years as an IT techo for one of the big four banks says you really are just speculating on how you think access to systems work. Believe me, banks take security very very seriously.
And the password length, whether a 4 numeric pin, or a 6 char password, or a 120 char pass phrase as I once used on access to public key cryptography keystores, does not matter if 1. The password is kept secret, and 2. The logon process blocks brute force guessing.
Also, the increased use of two factor identification is making passwords a thing of the past. So just make passwords easy for people to remember so they don’t need to write them down.
Among those breaches were brute force attacks.
APRA have had a very different view of the sector’s supposedly good risk management
“Amid clear evidence that risk management remains weak in financial institutions, it is apparent that boards and senior managers need a stronger, louder and more insistent voice on their shoulder urging them to think again. Someone senior and trusted. Someone independent. Someone with expertise in identifying and assessing risks. You can probably see where this is heading.”
A further disclosure
Prior to retirement I was engaged in a project to convince one of the Big 4 to essentially modernise their ICT capability. They used an off the shelf system and despite the techies being more than passingly receptive to very eager, the powers in that bank only bought ‘IT’ if it had one particular logo.
The only thing that bank took seriously (circa 2010) was its P/L, spending as little as possible, and embracing the status quo and a particular logo. As for security the management seemed to take the stance what the public doesn’t know won’t hurt the bank.
No offence as there were many techies screaming not just crying in the winds at that bank, at that time.
Then @grahroll’s link…
The details are paywalled but I see nothing that suggests that successful brute force attacks on individual accounts played any part in the announcement. If it is in the detail perhaps you could show us an extract.
Before this thread wanders off into broader problems with security in financial institutions (which I am sure exist) I still have not seen anything to support the idea that having merely 6 character alphanumeric passwords opens up personal accounts in Oz to brute force attacks, which is where we started.
That detail is never released publically beyond the basics as it exposes the Banks and other financial institutions to further attacks until they plug holes. Weak passwords, less characters, not allowing non alphanumeric characters are all security weaknesses that are discussed ad infinitum by security experts. Our Banking sector gets a lot of leeway when it comes to details in disclosures and at times to their implementation of security.
Enabling 2 factor authentication is a help as it helps circumvent most attacks, nothing is perfect but going better than basic is a good starting point.
You are correct - my assertion of cracking in less than a second involves the perpetrator having direct access to the bank’s password database. Nevertheless, six characters is way too few.
Oh, and to guess six alpha-numeric characters including as many repeats as you like one would need to make up to 62^6 guesses, or around 57 million. That would take just under two years guessing one per second.
…require passwords of more than six characters! If the bank has this flaw in its security, who knows what other flaws it might have?
No thanks - I am not remembering my several hundred passwords, nor do I expect most of those places to go password-less any time soon. Additionally, 2FA is two factor - password plus something you have (dongle, authentication app, hopefully not SMS). I cannot see passwords disappearing in the next ten years at a minimum - and possibly never.
If we have 26 alpha characters and 10 numeric there are (26 + 10) ^ 6 combinations, about 2.2 billion.
I assume you are raising 62 the sixth power because you are including upper and lower case plus other characters such as punctuation, which is not my definition. If that was the case 62 ^ 6 is 57 billion, not million.
For the purpose of defeating a brute force attack on your bank account or mine it doesn’t matter.
Is that what “A password requires 6 characters” means? Or is that specifying the minimum?
We should name the bank.
I suppose it’s not my bank because my internet banking password is a truckload longer than that (as is yours).
As has already been stated, a password of length 6 is reasonable provided that it is random alphanumeric and the system detects repeated login failures and after a small number of failures it locks the account out. (I think it’s three strikes for my bank.)
Add 2FA and there is even less reason to complain about a password of length 6.
The lockout counter is (or should be) against the “username”. It doesn’t matter where the attempts come from, same IP, similar IP, wildly different IP.
Only if the implementation is flawed. Logins against a given username should serialise against that username. (I actually see attacks similar to this against my honeypot, where multiple connections are made, but no request sent on any connection until all connections have been made, and then the requests are all quickly sent in parallel.)
It is so much easier to break the login by breaking the access device (e.g. recording keystrokes after using any viable exploit against the access device), hence the popularity of 2FA.
When you think that you can break the bank’s login process, you are going up against the bank’s security department.
When you think that you can break the access device, you are going up against sometimes very poor or non-existent security of a home computer, for example.
e.g. your typical remote access scam, which basically only relies on tricking a human being. No bugs needed. No brute force needed.
Ironically here the risk is innovation.
Stick to the mature access tech that has been worked on for decades and it’s safe.
Add new convenient tech (like pay by phone number) and weaknesses creep in - until that too matures through sometimes bitter experience.
If a person is in possession of the salt and the result of the hash and, if relevant, the username then: agreed, six characters will be broken quite quickly - it is too short to resist offline brute force attack.
If the attacker has taken the password database then all of that information will be available - potentially minus however the actual hash algorithm being used. An inside job would know that. A random attacker will have that as one additional and preliminary hurdle. (If the random attacker is himself a customer of the bank then he could use a known plaintext attack to test algorithms until, and if, the correct algorithm is found - before then proceeding to brute force another customer’s password.)
Alternatively, if the attacker can steal the password database, the attacker may be able to steal the code that implements the password checking and/or steal configuration information that identifies the hash algorithm.
57 billion - but can still be broken quite quickly under ideal conditions.
Interested parties could take the site down in their eagerness to confirm. (probably not really, but it is a choice of 4) It might be a form error, yet the restrictions as posted in the screen shot seem to all hold. I gave them a chance to consider it. Regardless the limitations on the password do not reflect well on their concepts of security management in my view.
That is one view. There are others about SMS or emailed ‘codes’ to process every time one accesses an account, that do not need to be reviewed here. Challenges are yet another security aspect but that seem to be losing favour to 2FA, and passwords continue to be the most basic ‘security’ feature, whether they are what they purport to be re ‘security’ or not.
Yes.
I meant from the perspective of security. Convenience is a whole other consideration.
Might be. Who knows. Maybe the web programmer read the “specification” that you included as a screen shot above and interpreted “requires 6 characters” to mean exactly 6. 
As long as I used and supported IBM Mainframes, the password was restricted to 7 characters. Non-case sensitive, and no special characters.
Nobody was ever concerned about this because every site I ever worked for implemented the limited tries and you are locked. Password expiry every month, and you could not reuse passwords for a year.
In other words, proper logon processes taken seriously.
Try imposing THAT on Internet users for their social media and Email and online banking and see how far you get.
