Australian Banking Security

Online Security is getting every day more and more important. It’s so common these days to implement secure password policies, which is at least 8 characters, with minimum 1 special character like @$# …. More and more cooperation’s taking care of Passwords  as nearly every day a new “hack incidents “ happens…

We all expect at least banks take care of secure password policies, beside SSL logins or Virtual keyboards. As I said “we expect” but its sad too see some of the banks are not meeting the minimum security requirements or at least our expectations or even the  ISO 27001 or PCI standards in terms of passwords.

This post is a  proof on how weak passwords polices are used in some of the Australian Online banking web sites. Yes , they do have SSL but knowing that these days SSL hacking is not “rocket science” , some of the PKI were compromised few times…

I have done a simple Pen testing via login to the SSL protected sites and entered manual passwords, and the result was shocking, at least for me 

My first example  is National Australia Bank (NAB)

1) Only 8 characters of Password is allowed

2) No special characters are allowed

Here is one more example from Westpac

They force users to use the “virtual Keyboard” but only 6 character’s of password is allowed!

My recommendation is do not trust your SSL too much and encourage your customers to use complex passwords, please

A special thanks for the Commonwealth and ANZ banks who has not just SSL, virtual keyboard but also 15 characters password selection choice.

This test will be continued, keep an eye more to come…

 weak passwords polices

The weak password policy finding is typically an indicator of one of two conditions during a test:

• A password could be easily guessed using standard authentication mechanisms.
• A password could be easily recovered after capturing crackable password hashes.

Password strength is a topic of serious contention within most of the organizations that we test.  There is a constant struggle between information security staff who want to protect the organization and the people who have to do the business that keeps it viable.

As IT and security personnel, when we ask employees to construct complex passwords, we usually end up with something like the following. As expected, we also get a similar response.

Easily Guessable Passwords

Creating password policies like this will rarely work because users identify ways to create weak passwords that comply with the implemented policy. Take, for instance, a password policy that requires an upper case character, a lowercase character, a number, and a symbol which must be eight characters in length. Some of the weak passwords that we commonly observe include things like:

• Spring2018!
• February18!
• Password1!

This isn’t nearly exhaustive because we often find company names, slogans, and other region specific root words exhibiting the same pattern.

Users select these passwords because they are easy to remember, easy to create, and conforms with the policy. The following XKCD comic illustrates this issue.

Attackers often engage in password guessing attacks like password spraying in an attempt to expand their access to other users in the environment. Having easily guessed passwords makes this expansion possible.

Easily Cracked Passwords

In addition to the ability to guess passwords, attackers often have the opportunity to crack passwords within an environment.  When an attacker engages in password cracking, they typically need password hashes to crack.

Often, hashes can be obtained without any special permissions in an environment. Abuse of protocols like Kerberos, Link-Local Multicast Name Resolution, and NetBIOS Name Service are typical attack vectors. However, they are not exclusive. Careless application of share permissions can expose backup files that contain hashes as well.

If passwords are short, then the attacker typically has an advantage. As an example, the BHIS dedicated password cracker can exhaust the entire 8-character password keyspace, cracking NTLM hashes, in a matter of a few hours.

For this reason, BHIS urges its customers to consider a password policy that focuses on greater length than character set complexity. We recommend the following:

• The minimum passphrase length should be 15 characters.
• Multiple dictionary words constituting a phrase should be permitted and encouraged.
• Encourage title case in phrases and allow digit substitution for words.

The length of a password has much greater influence on the attacker’s ability to crack that password in a reasonable amount of time (before your next password change) using brute force techniques. Another XKCD comic illustrates this concept.

Other Considerations

Having a strong password policy keeps attackers from guessing weak passwords and cracking hashes collected through various means. In addition to strengthening your password policy, measures should be taken to minimize or eliminate opportunities that assist attackers in collecting hashes.

In addition, users should be encouraged NOT to reuse passwords across multiple accounts. This is especially true when those accounts operate at different privilege levels.  An attacker who gains access to a single account may suddenly find instant access to many resources. If users maintain a large number of passwords and have trouble remembering them, the organization should consider the use of a reputable password manager application.

Where and how elevated privilege credentials are used should be carefully architected. Memory analysis with tools like Mimikatz can reveal plain text credentials of any complexity on certain systems. If possible, protective measures should be placed on these systems (like Credential Guard) to prevent disclosure. For ultimate protection, administrators should operate on administrative-only workstations that lack internet browsing and email capabilities.

Finally, for especially sensitive systems (like Domain Controllers) and internet facing logon interfaces that grant access to internal resources (like email and VPN) multi-factor authentication should be implemented. On internal systems, the technology should be usable with interactive (console logon, Remote Desktop Protocol, etc.) and non-interactive sessions (enter-pssession, psexec, etc).

Conclusion

A strong password policy should be one of the cornerstones of your security program. Users are constantly under attack using vectors like social engineering, phishing, and drive-by downloads. Without a strong password policy, the success of just one of these attacks could result in systemic compromise of an environment.

Banking Security