0

When writing about best practices for authentication, I find that today's best practices still leave gaping holes in security, specifically not solving the problem of password reuse by users - websites are currently sent the user's input which means they could be storing it without them knowing. It also means that a user that is tricked into visiting a malicious site instantly gives away their credentials.

When I talk of passwords, I believe that any authentication key, whether it be generated via biometrics, a physical key or a password should be forced to use this protocol.

I have been unable to find any such protocols online for this purpose, the current idea would be something of the sort (I'm not a crypto expert, this is merely an example).

1) The LoginID is passed to the server, the server responds with a user-set reply to validate they are logging in at the genuine site. 2) The user's browser is sent a cryptographic key linked to their account, when the user inputs their password, the browser first encrypts this key with the users password & then hashes it, before sending it to the server. The server should then follow best practices for password storage as currently advised.

In sumarry, what is needed: 1) A mechanism when authenticating that is clear to users that they are logging in at the correct location that they believe they are. 2) The website must never receive the user's actual authentication key (i.e. their plaintext fingerprint).

Why? I first thought of this when thinking about multifactor authentication and thinking it is rather a bad idea to transmit biometrics to anybody for any reason in plaintext, (over encrypted channels, it doesn't matter), as we have seen all too many times websites not taking adequate security measures, it is not so easy to change ones fingerprint. Included must be some form of mechanism to ensure the user does not transmit credentials to the wrong site. Hence I reccomend the two-stage login, the user login ID (which should not be a username or an email, it should be private), is entered, upon entry the user is sent the prompt they set, this could be an image or text or both, this acts as a way of preventing simple phishing attacks which aim to clone sites. THis is necessary to prevent phishing attacks else malicious sites will still mimick genuine ones, or unattentive users will fall victim. (I reccomend that the browsers flag login inputs as 'insecure', informing the user will be sent in plaintext, if websites choose not to adhere to this standard).

Again this is just an example. It just seems that it is not all too complex or costly to implement what would be a real advantage to user security. It would eliminate the need for a password manager & make password breaches a minor inconvenience. And as said earlier, it adresses the pressing issue of biometrics.

Again I'm no crypto expert, this is just a simple example protocol.

I have attempted to find information on protocols for this purpose but have failed. I have seen some answers on stackexchange reccomending such a thing, but not a dedicated post. I apoligise if this is a duplicate, the search terms on this matter predictably throw up irrelevant posts.

2

Welcome to the community.

What you've described is effectively a mashup of hash based authentication and TLS which isn't a bad idea in theory. However, this doesn't prevent phishing, it just prevents the discovery of the password. Your system would still be susceptible to reverse proxy attacks and pass the hash attacks just going off the top of my head.

Getting into identity management and protection, the root issue with passwords is not the interception process. We've built a lot of protocols around the protection of communications so even a clear text password transmitted through TLS is suffiently protected from MOST attacks. The issue with passwords is they are guessable, crackable, shareable, and don't do a sufficient job protecting the identities they are associated with. Everyone could use the same password.

So, knowing that passwords are inherently weak, the security industry is moving away from them as quickly as they reasonably can. As part of this, the Fido Alliance has been making major steps towards eliminating phishing and supporting the protection of authentication for users and services. In fact, using this frame work, Google has announced that they have totally eliminated phishing within their company. A pretty bold claim, but there is increasingly information backing it up.

For example, on January 1, 2019 there was a framework that used a reverse proxy solution to phish users with 2 Step authentication. It was literally a transparent layer between the user and actual service which passed through all information diligently between the user and the service. Using the custom reverse proxy, the solution builder was able to defeat multiple forms of Two Step authentication including SMS and email. The only authentication he couldn't defeat was FIDO through the use of U2F authentication.

I highly recommend studying more on the FIDO protocol here:

https://fidoalliance.org/

You can also see Google's two year study white paper on the U2F protocol here:

http://fc16.ifca.ai/preproceedings/25_Lang.pdf

  • Yes, when writing this I did think about reverse proxies, becuase I once operated one (legally) phishing instagram credentials (with permission). In regards to multifactor authentication, I am well aware single factor authentication is inadequate, it was actually thinking about biometrics I thought this necessary. The security issue here is that users cannot know what is done with their biometrics, like I said passwords can be changed, fingerprints not so easily. I realise advanced and more targeted phishing attacks will still get the credentials, but this protocol should mean they only get – Reality Jan 20 at 18:43
  • - continued - the credentials to that specific site, and it means their biometrics are not compromised. Currently if a user is phished their inputted password & biometric data (or other auth types) are compromised, this which they likely reuse across many other sites. This protocol would prevent this. It also, as already said, protects users from poorly configured sites (who don't properly store data), should they be compromised. – Reality Jan 20 at 18:47
  • Your protocol would make password replay very difficult. You'd also make it very costly for the server since it would require the use of individualized keys for hundreds or thousands of users. Hash tables wouldn't be helpful which is a nice benefit, but over all you've added a lot of overhead. Biometrics, at this time, are not well equipped for HTTPS authentication at least not any tech I'm familiar with. Can it be done? maybe, should it be done? no. BIO data should never leave hardware. Strong Something You Have should be required to prevent phishing. – Connor Peoples Jan 20 at 18:53
  • Isn't best practice to store nonces(salts) as part of key/password storage anyway? I'm rather making this point, BIO data should never leave hardware. This means it doesn't. I have glanced over the FIDO & webauthn specs and do they not require the user to have a phone with a specific application to achieve what I am setting out here? Isn't that more overhead? – Reality Jan 20 at 18:57
  • Salts are relatively small. Having PKI key pairs individually generated is quite a large task, not to mention you're having to perform that encryption/decryption back and forth. I'm going to stop the discussion here though, if you're looking for further input, a forum may be a better place. – Connor Peoples Jan 20 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.