My original point.
The length of a password or pin, or complexity of values allowed or enforced is completely irrelevent.
What matters is the access environment.
A system that swallows your card or locks out access after 3 attempts is impervious to ‘brute force’ password guessing.
A system that forces password changes on a regular basis may be a pain in the arse for most users, but will protect against userid/password combinations that may become leaked onto neferious Internet sites.
A system that uses one-time limited time validity passwords as with codes on RSA tokens or sent via email or sms are far better. The neferious actors have maybe only a few minutes to try to access.
1 Like
With two exceptions (at least)
- a password that is not sufficiently random (e.g. too easily associated with the person or the username) is weak and vulnerable in any access environment - hence seriously secure environments will force all users to use passwords that are generated by the system (by way of example, if your birthday is Jun 29, happy birthday
but don’t use a PIN of 2906 or 0629) - if the bank itself is compromised then 6 characters really isn’t enough, the assumption being that there are therefore no limits on how long the hacker has to brute force a password / no limits on the number of attempts (since it can be an offline attack)
The only defence, after the fact, for the second item is to force all users to change password, as a one-off, but failing that (for example, if the intrusion is never discovered) forcing occasional (periodic) password changes helps (as you suggested).
For the record, the default period of validity for TOTP is 30 seconds - and I can see from my bank-issued RSA token that it is using 30 seconds.
1 Like
30 seconds eh. Well that rules out that usage on phone or email delivery systems.
There is no way you could reliably deliver a TOTP in that limited amount of time before expiry.
there have been a little bit of back peddling on that requirement due to that password managers are equally a risk to your safety online and certainly in many case completely impractical, think computer system, firsts time email login, password manager login
Proper system is inline with my statement
System highly limited to number of incorrect attempts an a secondary key
The regular changes are still recommended as it is irrelevant how looooong the password is. once a key logger, a database breach, reverse decryption or other magnitude means a password is captured by an actor and usable in the highly complex state
a changed password means there is a strict time limit to the actor must used it and the secondary key of now highly prevalent multi-factor technologies . in many cases an enforced requirement of systems you will use.
In fact long complex passwords are useless the new recommendation is to pass phrases with common but unrelated words. such example is
Apples saved the aliens
Your last point is my understanding of the current advice for long passwords. Use a pass phrase instead. If the access system allows it. And that is a big if.
“My cat is 12 volts” would be just as safe as say
“Gr3gr01&qw3rty1”
In fact the second is 4 less characters, so 32 fewer bits as a key if using one byte encoding in UTF-8.
Both are beyond the brute force crackability of current computers in useful timescales, but which could be better remembered without writing it down or using a password manager.
2FA can be tricky. Imagine travelling ‘not here’ and you need some money transferred to your transaction account. Only takes an app and a few seconds, but your +61 mobile might or might not work, cellular or wifi, so too bad for 2FA? Email is not universally embraced for getting a OTP as primary or backup when one cannot receive a text. Ringing in? Some financial institutions will work with a customer but time (and cost) waiting on hold can be ugly, and not all are as welcoming to ‘get it done’ as others.
1 Like
One of our banks did not allow special characters or spaces, although it has offered an RSA key for many years.
Would a brute force attempt first start using a dictionary based strategy? IE assume the pass phrase is made up of a random sequence of the most common English or other language words. Is the outcome that follows a very simple problem in computer time to solve compared to a totally random sequence of similar length?
Notes:
Both of the examples offered use very common words, with some added complexity due to the use of spaces and in the second numbers. While there are more possibilities of common use words ( hundreds or thousands) than a single character the choices are still limited. Both examples offer just 4 words. The option of first letter Capitals, use of a space or not and uncertain location of a number or two make the second example more effective. Note many sites require at least one number in the PW. Most everyday non geekified users may not be aware that a space is permitted.
It may wisely add to the complexity if one is using a pass phrase to include at least one uncommon word not likely to be found in everyday language. The odd name of a locality, foreign place, deity, botanical etc. Even the use of “12volts” as a single word may add sufficient complexity?
One view on complexity. A little dated hence the times to break suggested may now be significantly less.
I’d assess the phrase “Apples saves the aliens”, depending on dictionary as one in a 2 x 10^12 chance. IE 1 in 2,000,000,000,000 on the assumption a 1000 word dictionary is adequate. Potentially broken in minutes?
Are there risks of being too predictable?
2 Likes
Yes and no.
With TOTP nothing has to be delivered. Both the server (the web site) and the customer device generate a code that is derived deterministically from a shared (long random) secret key and the current time divided into blocks of, by default, 30 seconds. So the only requirement is that clock skew is below a threshold. With HOTP, the principle is the same, nothing is delivered, but instead of the current time, a sequence number is used.
Secondly, both TOTP and HOTP can make provision for ‘skew’ between customer device and the server. That is, for example, since the code changes every 30 seconds (by default) with TOTP, the server can be configured to accept the code for the previous 30 seconds (customer device is behind) and the code for the next 30 seconds (customer device is ahead). However that extends the period of validity from 30 seconds to 90 seconds.
Or in the case of TOTP, the server can just reject the code and make the user go again - since trying again may paper over the clock skew.
Thirdly, 30 seconds is only the default with TOTP. It is open to a web site to use a higher value e.g. 60 seconds. That then tolerates higher clock skew (but obviously the choice of a much higher value does extend the period of validity and hence period of time where an intruder can misuse the code).
Where TOTP is implemented on an internet-connected device (computer, or mobile phone, or tablet), clock skew is likely to be negligible i.e. most devices are using NTP to synch the time.
But let’s say that a code actually has to be delivered (via text or email). In that case, the validity period is purely arbitrary (the code can simply be randomly generated by the server and the server decides how long the code will be valid for - and that period does indeed have to be commensurate with the delay introduced by the delivery mechanism).
In my experience text messages are usually delivered very quickly, close to instantaneous, but occasionally a mobile service provider will have some major SNAFU in progress and it might take hours and it will clearly fail as a 2FA mechanism.
The real problem with 2FA via SMS is that in rural and remote areas, the customer may have no mobile service at all at home, so 2FA via SMS does not work unless mobile-over-WiFi (aka WiFi calling / WiFi texting) works. I have heard of laughable stories where customers log in to a web site, get in their car, drive to a nearby high point, receive the SMS, drive back home in a rush, and enter the code on the web site.
2 Likes
An entropy calculation would say otherwise I suspect.
A randomly generated password of length 15 comprising printable ASCII characters has 98 bits of entropy, according to the software I use.
A password of length 18 comprising randomly selected words separated by spaces, well, it is much harder to calculate the entropy because it depends on the exact contents of the dictionary and because it is just much more difficult e.g. dealing with the different ways of partitioning but … I would be surprised if you could get close to 98 bits.
As a warning sign … a certain proprietary global location package (that I don’t recommend you use, but that is for completely unrelated reasons) identifies uniquely each of the 3m x 3m squares on the surface of the earth - all 64 trillion of them at most - using 3 words, chosen from a dictionary of 40,000 words. Entropy: 46 bits.
(This is not a direct comparison because some 3 word combinations may be much longer than 18 characters and some of course may be shorter; it only uses exactly 3 words, not more, not less; the dictionary may be larger than the average person choosing ‘random’ words - however I assume the dictionary used does not contain ridiculously obscure words since the system has to be usable even for NESBs living in an English-speaking country.)
You would need to write a program I think to work out the true entropy. Until you’ve done that, the assertion that a passphrase is just as safe is really just speculation.
2 Likes
Remember that you as a hacker do not have the opportunity to try trillions of possible word combinations.
You only get maybe three tries before the access is blocked.
1 Like
Unless it’s an offline attack.
If you only get 3 attempts then a 6 digit PIN is safe enough, which was kind of the starting point of this topic - so neither longish passphrase nor similar length random printable ASCII are required.
An interesting additional scenario for offline attack is … the user uses a local password manager (tick), the user has chosen a passphrase to lock the password manager (as recommend by you), the user’s computer has been partially compromised so that a copy of the encrypted database of the password manager has been taken but the password manager password was not itself captured.
2 Likes
But if you are offline, how do you test access to the online system with the password guesses?
This is not like having some encrypted text that has been scrambled with a known algorithm and can test millions of guesses per second until something legible pops up.
Well first of all my comment was in response to the claim that “long passphrase is as safe as slightly less long random password”. The assumption has to be “all other things being equal”, whatever the attack scenario is.
For the original example of an internet banking password, the two offline attack scenarios would be:
- the bank itself is compromised (and the entire database of hashed passwords may be taken)
- you stored your internet banking password encrypted on your own computer and your computer is compromised (so the underlying encrypted file may be taken - that could be a password manager or it could just be an encrypted file / file system).
As a mind-boggling but real life example of the former … there was an occurrence where a database dump was accidentally left on a publicly-exposed server so that someone was able to download the database. (Since it’s only a copy, the hacker can’t directly modify the database and it isn’t even entirely accurate to say that the bank was compromised - but the confidentiality of the information was definitely compromised.)
As a random FYI, the hacker can test whether the algorithm is known if the hacker is himself a customer of the bank, since the customer then knows the plaintext and has access to the hashed version. (This is without even including the possibility that the compromise involves the hacker also taking enough code so that the hacker can directly find out the algorithm.)
Also, best practice recommendation is generally “don’t invent your own crypto algorithms”. So most banks will be using standard known algorithms. It is just a question of figuring out which one and with what parameters.
And will need to know the key used to encrypt the plaintext into cryptotext. Otherwise you are back to brute force guessing. Over multiple possible algorithms.
But the list of common algorithms is small. Most would use 3DES or AES these days if browser based banking apps.
Could be anything if proprietry client / server apps.
Passwords should be hashed, not encrypted, unless there is an overriding need for the server to have access to the plaintext password.
Even so
This.
But we go around in circles. If the password is stored hashed, then you can run your plaintext password through a known hash function, and if the result matches, bingo, you now know the password that you already knew.
Now try and find anyone else’s hashed password.
No, bingo, you now know that the web site is using the particular hash function that you just tested.
As an aside, it is often possible to guess or at least narrow down the hash function just from the length of the result.
Then you use a brute force attack which will be successful against Westpac’s modest requirement as documented in the OP (length 6, letters and digits only, no special characters).
(The OP doesn’t state whether “letters” means lowercase, uppercase or either.)
It may be successful against a length 18 phrase of random dictionary words but that hasn’t been measured yet i.e. what entropy.
2 Likes
But the password is not just a standalone thing. If hashing is used rather than encrypted password, then randomly generated ‘salt’ values are added to the password before the hash value is calculated.
Unix way back in the 1970’s used a fairly modest 16 bit salt value.
Today’s systems would use far more sophisticated salting to turn even a 6 alphanumeric password into something very hard to brute force guess.
Every bit added to a length doubles the computations.
The salt value is typically stored in plaintext on the server as it must be. If a compromise has led to a hacker having access to the hash values then you can very reasonably assume that the salt values are also available to the hacker.
As a consequence, it is actually desirable for the salt not to be too long (although I suspect that that is a largely theoretical consideration). The point is that given that the salt is available in plaintext, you don’t want too much entropy in the salt relative to the entropy in the user’s supposedly secret password.
Take a look at /etc/shadow on a current Linux system and you will see that the salt value is length 16 (although I am not sure whether that is base64 encoded or not).
16 what? Characters? How many bits that is depends on encoding.
It is between the second and third $ symbols in the /etc/shadow text file.
Presumably binary.
If the encoding in the file is only characters 0 to 7, then it is octal. If chars 0 to 9 and a to f or A to F then hexadecimal.
If 0 to 9 and a to z and A to Z and a couple of specials then base64.
More than that then ASCII or later encodings.
