Autocomplete

There is lots of advise on how to disable autocomplete, or copy/paste for input forms especially password forms. This is mostly well meaning, in that there is a perception that this makes their sites more secure, when in practice this makes them less secure.

The correct security advice is to recommend that users use a password manager, and that the web-page assists the password manager by setting the autocomplete="current-password" on the field so that users can use long, complex, randomly generated, and unique passwords to log in quickly.

If you make the user type the password they will
1. hate you
2. use a simple easily remembered password (weak, not unique, & short)
3. users that already use a password manager will give up and go elsewhere

autocomplete="off" is almost universally ignored by browsers, and is always ignored by password managers. Some password managers have an option to respect autocomplete, but if you turn this on it makes the password manager useless.

if autocomplete="off" is set the password manager has to guess which fields are which on the form. They do this by looking at the field name, the input type, and the label fields. But there is no standard as to how these are named.

Perhaps the most unfathomable aggression against the user is this plugin:

The jquery.disableAutoFill plugin randomizes an input’s name attribute by default. When the form is submitted, the plugin restores the original name. This prevents auto-completion for all browsers (includes third-party auto-completion extensions) but doesn’t necessarily help with login fields. https://terrylinooo.github.io/jquery.disableAutoFill/

On the Mozilla page about autocomplete it tries to remind developers about the principals of what the web is for:

It is important to know that if you turn off autocomplete, you are breaking the rule 1.3.5: Identify Input Purpose in WCAG 2.1. If you are making a website that should follow WCAG, you should use autocomplete with autofill. https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html

https://www.ncsc.gov.uk/blog-post/let-them-paste-passwords
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete
https://developers.google.com/web/fundamentals/design-and-ux/input/forms

Right to Repair

We are at a strange junction of history. We have unprecedented access to technology. The number and capability of single board computers, sensor chips, even things like FPGAs that are available to the hobbiest, is amazing.

At the same time we have a massive removal of normal consumer rights from the ability and the right to access their own technology. Consumer devices are sealed shut with glues, special screws, warning stickers that threaten the user with dire consequences should they have the tenacity to break them. But the main method of sealing goods is to do it with software, and the aid of copyright protections.

The Digital Millennium Copyright act in the US and many similar laws make it a crime to break a software lock that is protecting a copyright work, even if the reason is legal. So we have seen a explosion of software in devices, and as software is a copyrightable work, all a manufacturer need to do is put a lock on that and they have the law to stop anyone using the device they sold to you in ways that they don’t like.

Apart from this being a horrible business practice, it is changing our society into that consumerist culture. In a time of climate change we should be conserving resources and minimising carbon footprints. Most of the carbon footprints of devices comes from their manufacture not operation, so extending the useful life makes a large contribution.

There is substantial support for the “Right to Repair” across Europe and the US at the moment. There are a number of right to repair acts at state level in the US some making progress, some not. In Europe we recently got repair legislation for some appliances in terms of requiring the supply of parts from manufacturers for 10 years.

The battleground is now about mobile phones, though other electronic devices are also in the mix. So go to repair.eu and sign the petition. Or in the US repair.org and lobby your state senators about the Right to Repair.

The use of SMS (Text Message) to deliver a One Time Passcode (OTP) is not recommended.

Using a text message (SMS) to deliver a authentication or security token to a user has been useful in the past. It is still used in many systems, but we need to phase this method out.

Messages are transmitted across the global SS7 network, there is no encryption, authentication, or integrity protection on the SS7 network. Access is limited (Mainly telecom operators, but wider access is developing) There have been a few malicious actors detected on this network, but this threat is growing.

The more common attack method at the moment is to Social Engineer the mobile operator to do a SIM swap, and while Mobile Operators have a poor security record in protecting customers against number takeover attacks.

While the Mobile Operator is attacked in this there is little incentive for them to protect customers against this as their business is not affected. This has been the main mechanism of SMS OTP compromise so far.

The responsibility falls to system designers not to rely on SMS to securely deliver these messages.

You can use of email to transport the OTP, or the use of an encrypted messaging service such as Whatsapp, signal, telegram as an alternative to SMS.

The use of a Time based OTP is recommended, this should conform to the RFC-6238 standard. Google Authenticator is widely assessed and recommended tool for using this.

Attacks and exploitations reported

https://krebsonsecurity.com/2018/11/sms-phishing-cardless-atm-profit/

https://krebsonsecurity.com/2018/11/busting-sim-swappers-and-sim-swap-myths/

https://bitcoinmagazine.com/articles/investor-lawsuit-brought-against-t-t-mobile-sim-swapping-hacks/

https://motherboard.vice.com/en_us/article/mbzvxv/criminals-hackers-ss7-uk-banks-metro-bank

https://thehackernews.com/2016/07/two-factor-authentication.html

PCI DSS Standards

https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf

Use of SMS for Authentication

PCI DSS relies on industry standards—such as NIST, ISO, and ANSI—that cover all industries, not just the payments industry. While NIST currently permits the use of SMS, they have advised that out-of-band authentication using SMS or voice has been deprecated and may be removed from future releases of their publication.