Or perhaps more conveniently, every time one changes the password, but not on every login.
For some entities, only on password change would be too lax. It all depends on the individual entity as to what security measures are appropriate.
Not sure of what part of a one time code each and every login is to be considered ‘lax’.
For MyGov it’s every log in.
For some banks and financial services it’s every log in, and certain transactions. My preference is an RSA token, still used by some but not all banks. Partly because mobile service is not assured where we are.
Even AGL who do more than gas and electricity these days require a 2FA for certain actions, and send a code to your mobile or email if doing a change via a phone call.
That many allow a reset via email and may use optionally email for 2FA may be worth further consideration.
The RSA token is something I needed for logins for many years, but it is for one system.
The email delivered one time code is problematic as there is usually a delay in the email server processing and mostly by the time I get it, the code has expired.
The sweet spot at the moment is SMS delivered code on my phone, as for Mygov and my banking and Internet provider. That is usually delivered in seconds.
Just a misunderstanding. I edited my post for clarity.
For some banks it’s never on a log in but is on certain transactions. (Hence for example if the password is compromised, the bad actor has unlimited read access to the account e.g. account balances and transaction history and stored billers and payees.)
Because who needs encryption or authentication? Even email nowadays contains at least a modicum of encryption, but not SMS.
Really? That is not the point of a one time code.
While these are definitely bad points of SMS for general communication, this is less of an issue in the specific case of an SMS being used to deliver a code for 2FA. SMS is not terrible for this purpose.
The sweet spot for me is an open source 2FA app doing open standard OTP.
My password manager is piece of paper that lives under my desk mat. If my laptop hard drive dies doesn’t matter. One day I’ll get around to putting a copy on my encrypted cloud storage.
At home I use a long passwords all the time and they are unique for each site. Its simply done by having a password that’s in two parts. The prefix is unique to the site and its just like a regular password that’s followed by a longish password that’s common to that set of passwords. The second part doesn’t require updating and easily remembered because its used often. Don’t like 2FA for home if relies upon my phone, phones die at inconvenient times.
At work I use a keyboard pattern which I move around the keyboard (shift it all to right or left by one key) when you are forced to change your password. With a keyboard pattern all you have to remember is the pattern and its starting point.
But some sites don’t support ALL of the not-letter and not-number characters on a standard keyboard. Several times I have created a a password and it hasn’t worked (either password creation has been accepted but then next time password will not work, or password creation fails) because one or more of the characters I chose from keyboard was not included by the programmers for that site.
Apart from character choice, some sites/devices are inconsistent about length too.
For example not all PIN lengths are restricted to four numerals. This is a good thing, provided all the places where you enter the PIN recognise when you enter your longer PIN.
Other example is the passkey for a WiFi connection. The connection I was dealing with needed best security and the downstream device said it supported the correct standard, and the standard allowed for a 63 character passkey … but the downstream device timed out long before the full passkey was entered (no matter how fast I typed).
1 Like
As long as the prefix cannot be derived in any predictable way from the site, that approach is somewhat acceptable. At the end of the day though that is reducing the strength of the password - depending of course on how many passwords are in the set of passwords.
cut-and-paste?
Whether you like it or not, that is where logins are going. More sites are enforcing 2FA to either login, or access some functions.
But it is good to have a unique password for every site since it may limit the damage if a nasty type gets hold of one of your passwords somehow. And when you get one of those emails one day that quotes your userid and password and demands you pay bitcoins or your compromising photos and videos will be released, you know which site has been hacked.
I personally think that the traditional password is something that should be abandoned in favour of one-time single use passwords with a lifetime of a few minutes maximum. Nothing needs to be remembered. Or written down.
That is 2FA.
To be fair, the post referred specifically to “phone” (which I take to be mobile phone). You can have 2FA without involving a mobile phone.
Many people in rural areas are unable to receive SMS at home at all - and hence that particular technology choice is relatively useless for 2FA.
If the 2FA involves industry standard technology (TOTP, HOTP) then you can have 2FA simply by doing what your mobile phone could do for 2FA but doing it on an independent computer i.e. not the computer that you are logging in to the e.g. web site on. (So, for example, if the web site “requires” you to use the Google Authenticator app on your phone then don’t. Just run a standard authenticator program on any other computer.)
Do you have an example implementation to link to?
Not necessarily, depending on what is meant by this.
2FA implies that there must be two factors. The two factors are chosen from
- something you know (e.g. a password)
- something you have (e.g. a mobile phone or a security token)
- something you are (i.e. biometrics - bad bad bad)
So if it comes down to the second bullet point only then it’s 1FA but the one factor just changed from the first bullet point to the second.
Of course I do. RSA tokens have been around for many years with rolling codes changing every minute. Likewise car remote keys, same thing.
Rolling code apps can be on any sort of computer including mobile phones. Delivery via SMS or Email is not the only way one-time passwords can work.
For completeness customer friendly systems give the user a choice of SMS to a mobile, a (robot) voice call providing the token to a selected registered number, an email, or an authenticator (security token). Without debating the security of any of those choices one has to wonder if there would be a situation none of them worked but the customer had access to the account and triggered a 2FA handshake.
Oh, OK, I thought you were possibly suggesting something else again.
For the scope of what you are imagining, probably not. If you are accessing a web site and triggering a need for 2FA then you can access email, probably.
Email as used in practice is though likely the least secure of those 4 options. (Email could also cause a cascade of 2FA, where you need 2FA to get into your email to get the code to get into whatever you were originally trying to get into. 
)
However that muddies the waters because when you receive a code via e.g. SMS or email then that code can be completely random or generated by an algorithm unknown to you, but it must be communicated in some way to you v. when you use something like HOTP or TOTP on a mobile phone, or like a security token absolutely nothing needs to be communicated (you could be completely “off the grid”) but of course that means that the algorithm has to be reliably executed in two places at the same time to produce the same result.
To answer your question, what about: I am trying to gain physical access to a secure remote facility that is completely off the grid. To do so I use 2FA. The first factor is a PIN that I know and I key on the PIN pad - which then triggers the demand for the second factor. The second factor is based around something that I have - but I forget my mobile phone running the authenticator app / security token. 
Using telepathy to access that off-grid location then? 
If you can access something you must have something to access it with, eh? That should be one of the 2FA media choices.
Considering the OTP is time limited if communicated well it would not always provide clues to what site or account or transaction it will activate. As a practical matter I would not be to worried unless that email clearly showed MyBank and MyAccount information and the perp had MyLogin (which I could not know).
Yeah, I’m not too worried about use of email for sending OTPs.
It’s just a comment about how easy it is to intercept each of the 4 options - and the fact that the email can’t really be guaranteed to be independent of the device you are accessing the web site on. So an emailed OTP is kind of like 1.5FA.
That is, if the nefarious party has (at one time) remote access to the PC where you are logging in to the web site, the nefarious party very likely can access your email - unless you take your security very seriously, and more than likely in that case the nefarious party would never have gotten remote access in the first place.
I would think that it is nearly always possible to work out which site the OTP is from.
However, as you say, the communication would not include other details (e.g. username). So the nefarious party would have to obtain those details some other way.
To me the point about OTPs is that each password/pin/phrase is usable once, and time limited.
One does not have to remember it since it is system generated.
It is tied to a device you must physically possess, be it a token, or a phone.
If the OTP is intercepted in some way by a nefarious person, they have only a few minutes to try and login. On a token, it cannot be intercepted. On a phone, could be with spyware installed. On Email, easy if someone has access to your account. So OTP delivered on Email is inherently unsecure and subject to delay in server processing.
So if your userid for some site gets leaked and put onto the dark web, who cares. There is no password. And many sites use an email address as the userid, so that should be considered public domain knowledge anyway. No secret there.
1 Like
