TechTalk About Passwords

1

Westpac has advised (June 2023)

Customers have expressed to us that they want to be able to set longer and more complex passwords. Therefore, we’re introducing a new password policy to give you a greater degree of flexibility to create passwords that are unique and meaningful to you.

What do I need to do?

Soon you’ll be prompted to update your Online Banking password when you sign in. Changing your password is mandatory, however, you’ll have the option to skip up to 3 times to enable you to do this at a time that better suits you. Your new password must have:

• between 8 and 30 characters
• at least 1 number, letter, and special character (@ # % ^ etc.)
• no more than 2 repeating characters in a row (AAB is ok, AAA is not)
• no spaces
• upper and lower case letters allowed

For your security, do not share your password with anyone, and avoid using your passwords from other online accounts or something that could be easily guessed e.g., your name, date of birth etc.

3 Likes
2

No spaces? What a stupid password policy. That effectively stops the use of pass phrases.

3

Back when a particular system allowed a backspace as a password character. I do not know if it was more secure but since the cursor stopped echoing during password entry (setting or logging in), showing only a blink no matter what was entered prior to the ‘carriage return’, a typo could get one locked out requiring ‘systems’ help…

The no spaces might indicate their IT group is overweighted by MicrosoftWindowsProgrammersWhoPrideThemselvesOnLongVariable control names? Who needs spaces when caps do it, eh?

4 Likes
4

8-30 characters and inclusion of special characters is certainly an improvement. “upper and lower case letters allowed” (my emphasis) … I hope means that mixed case is significant as well as allowed. The 6-character passwords could have a mix of upper and lower case, but the case was ignored.

I wonder if they will also add genuine MFA at login time as well?

5

It is about parsing the inputted data. Prefill the field with spaces, in ASCII that is decimal 32, then once found that is end of string. So no spaces allowed in your password.

Far more sensible is prefill with nulls, that is ASCII decimal 0. Pretty hard to use a null character in a password.

And backspace is ASCII decimal 8. Perfectly legit.

6

Using decimal to describe hex (binary) fields? No wonder software quality has declined since the days of display code when it took some talent to discover an end of string/line (blessed be the common decks).

s/a dinosaur :laughing:

3 Likes
7

A more sensible approach is to trim trailing spaces (i.e. the last non-blank char defines end of string) - so that then “Super Secret Password” is a valid password. Of course that means that "Super Secret Password " is not a valid password but allowing trailing spaces is fraught anyway.

If you really want a password phrase then another approach from the bank would be that they simply delete spaces from your entry - so that “Super Secret Password” will work but will not be a distinct password from “SuperSecretPassword”. The reduction in security from deleting the spaces would not be substantial, particularly if the total length is high anyway.

1 Like
8

For that to work you world need to parse from end of field backwards until the first non-blank is found. Perfectly reasonable. Some computer languages have that built in.

Done it myself in languages that do not have that.

And why is the space character any different in terms of a password than any other character? It is just a code that doesn’t happen to display.

9

I guess you would have to ask Westpac that, for the answer as it pertains specifically to their system.

Two generic reasons that could apply:

  • If a proportionally-spaced font is used and/or HTML is used then it can be visually difficult or indeed impossible to distinguish “Super Secret Password” from “Super  Secret Password” (you may have to cut and paste in order to verify that the second password has a key-bounced i.e. doubled space after the word, Secret, and I’ve had to hack it around anyway in order to override this forum’s software behaviour, without which it would be literally visually identical). Similar applies to a single trailing space.
  • If there is a “broken” implementation that passes user-supplied text around without adequate quoting, encoding, escaping etc. then space and indeed other punctuation characters can create risk of denial-of-service, malfunction or in the worst case security failure. (It can be argued that if the application knows that it does not do adequate quoting etc. but it does reject any user-supplied text that contains any such problematic characters then the coding is not broken. It is just an implementation restriction and may or may not be consistent with the business requirements.) There are solid security reasons to reject up front any problematic character even where attempts are made to provide adequate quoting etc.
10

A third is how the password coding handles spaces. If it records a space as & nbsp (space between & and n is deliberate as discourse recognises it as a coded space); or &#160, then the number of recorded characters is increased by 4. This would chew into its password length limitations and could cause errors for ≥16 ASCII characters plus a space to be rejected. This would confuse the layperson.

1 Like
11

I don’t buy any of that. Whitespace, which includes non-displayable codes like space, tab, backspace, newline…etc, should be simply considered for password purposes as a delimiter between words in a passphrase.

Any whitespace before the first word, ignored.

Any whitespace after the last word, ignored.

Any whitespace between words is simply a delimiter treated as a single char code to be included in the password. Lets just say a space character.

Doesn’t matter how clumsily a password cut and paste effort is done, or accidentally typing in more than one space between words, any half decent parser will sort it out. Regular Expressions have been around in many languages since the 1970s. One line of code would do all the input validation required.

A multiword passphrase easy to remember given 30 characters beats the hell out of an impossible to remember one word convoluted one.

1 Like
12

Yep!
I just leave the spaces out.
As an aside not all sites accept special characters. It’s restricting one to the upper and lower case 26 alphabet and 10 digits. Spaces are typically not permitted.

Yes, I’m changing the point of discussion somewhat. Providing the pass phrase is long enough is it at all relevant to consider special characters? Most of us use very few in our daily typing, hence remembering which and where in the phrase might also be asking too much.

Being able to use an emoji which one might find memorable because of the phrase wording or site might brighten the day?

13

“It depends.”

It depends on what technology infrastructure sits between the user and the backend.

For example, a non-breaking space being passed in a URL will generally be firstly UTF-8 encoded and then %hex encoded. So it won’t arrive HTML-entity encoded (contrary to what @phb proposes).

But on the other hand, if the non-breaking space is passed in HTML text or in an HTML tag attribute value then it might well arrive HTML-entity encoded (exactly as @phb proposes, but it could alternatively arrive UTF-8 encoded and that’s it, or not encoded at all and that’s it). However there isn’t a clear answer for whether it would arrive using a named entity (nbsp) or a numbered entity (160), and if numbered then unclear whether it is expressed in hex or decimal. (In XML it would always be numbered in the general case.)

Either way though that has to be catered for in the backend in order to reverse those transformations. If the backend is not expecting to do that then the encoded value may end up being literally included - potentially presenting risks to the backend.

In the case of a password, provided that the user types the password consistently and provided that the technology infrastructure handles it consistently, the password might work anyway, and the user might be blissfully unaware.

However this will always be vulnerable to code changes e.g. some developer notices X years down the track that, hey, we aren’t protecting against / handling properly any of this silliness, fixes the problem, and then the user can’t log in.

I can tell you for a fact that I have seen cases of a user cut-and-pasting text into an application where the application was expecting only printable ASCII but the text actually contained a non-breaking space (instead of a regular space, a difference that is impossible for the user to see) … and then the user contacts IT asking why the field value is being rejected as “invalid”. (In this case, no transformation was being applied. The application just saw the non-breaking space character and rejected it.)

Only if coded to do that.

The best case scenario is that an actual unencoded non-breaking space ends up in the password (and gets hashed along with the rest of the password). I would in some respects consider that a commendable password :wink: but only if you know that the character will be accepted, and not encoded, and you are prepared to take the risk that a future coding change breaks your password.

1 Like
14

Quite right, it is all in the password validation, and it seems there are no consistent ways of handling password entry.

But even sticking to printable characters, numbers, and a set of special characters can lead to problems.

Saw an example of a URL the other day that had replaced one Latin alphabet ‘O’ with a Greek alphabet omicron ‘O’. They are different encodings, but very hard to tell the difference between them.

Likewise what’s different between ‘l’ and ‘I’ ? One is a lowercase letter, and the other a different capital letter. In the font on my browser anyway.

15

If you are limited to printable ASCII then this (Greek alphabet) is one problem you won’t have.

Your other example, yep, could be confusing. That is one reason to prefer a serif font e.g.

Likewise what’s different between ‘l’ and ‘I’ ?

Of course the user may not (readily) get to control the font. That is often (usually?) controlled by the web site designer.

16

And what these days is limited to good old ASCII? Got an old PC still running MS-DOS?

17

It is not that the underlying technology is limited to ASCII (as you say, no current operating system would be) but instead the making of a conscious business decision to limit a field to ASCII. Some reasons to make such a decision:

  • interoperability with peer systems
  • compatibility with earlier systems or earlier specifications
  • no business need for anything other than ASCII (and taking a cautious approach that allows a more considered expansion of the functionality in the future)
  • security

A fun security attack against systems that foolishly allow Unicode encoded as UTF-8 but without any real need for it and inadequate testing of the implementation is overlong encodings.