79

There are a variety of reasons that a company may not want to offer a federated login option. Some of them include the following: People don't necessarily protect their social media accounts very well. A company may want the ability to require a strong password or 2FA to log in, and that's harder to do when you use a third-party login. Also, services may ...


75

This seems like a very wrong medium to send such information via. Email is used for the same reasons Social Security Numbers get re-used as account identifiers in the US: Ubiquity. Not everyone has a Facebook account. Not everyone has a Twitter account. But almost certainly, anyone with Internet access has an email account. It is a reasonable expectation ...


66

RFC 4226 (HOTP) would still be vulnerable to replay attacks in some situations. In the case of old fashioned key fobs, where you have to press a button to unlock the car, imagine someone who has brief access to the key fob while you are out of range of the car. The attacker can press the button once, record the code transmitted by the fob, and then hurry ...


57

PBKDF2 and other key stretching algorithms are meant to be slow and take the same amount of time whether the input password is correct or incorrect. To reduce computational load and latency for your user, the API should authenticate once via login credentials and issue a revokable or time-limited session token that is verified by a simple lookup.


55

In addition to the excellent reasons already mentioned in the other answer: Single sign-on / federated authentication means the identity provider knows what site/service you're signing into, and when. Lots of people might not want Google or Apple knowing about every site they sign into, and in particular might not want that information exposed when using ...


53

When I have a public/private RSA-keypair with 4096 bit and I remember the private key without storing it anywhere, is it something I know? Yes. When I write down or store the private part of a public/private RSA-keypair with 4096 bit, is this then considered something I have? No. The authentication factor is not the sheet of paper where the key was ...


45

Unless other authentication methods are involved (for example 2FA, etc.), if a correct email and the corresponding password are sufficient and necessary to log you in, then I see no security issues. The reason is simple: the authentication and authorization process doesn't change. However, if for example 2FA has been enabled for an account and the second ...


37

Tackling this from an engineering perspective, it’s not necessarily trivial to provide third-party login services. OAuth2 does make it easier, but you can’t technically just slap a login button on your page that links through OAuth2 (or whatever other federated protocol) and not have to do anything else. For example, Google actually has some pretty specific ...


27

While you correctly identified problems with e-mail, a mail based verification is still considered sufficiently secure for many cases. While there are alternatives like SMS based verification, automated phone call or even snail mail, these are not as easy and cheap to use as e-mail. The optimal security measures are usually a balance between usability (i.e. ...


25

In answer to your main question, AES256 is secure as far as we know into the foreseeable future. However your authentication scheme has several drawbacks. First, if any request where the token is sent is compromised, or if a the user installs a malicious addon that can grab the encrypted user name from their browser, that account is forever unusable. You ...


24

No. The attacker cannot obtain the encryption key from the plaintext and the encrypted text, because AES is resistant to known-plaintext attacks. See details in the answer on Crypto SE. I'd suggest you to review your design. Making user name secret can lead to many problems. For instance, if user needs to report a problem, how can user tell user name if it ...


23

When people talk about biometric authentication for the web, usually they are referring to the Web Authentication standard; a new, standardized method of user authentication which has been implemented in many popular web browsers. The web authentication standard does allow users to sign into websites using biometric authentication (e.g. fingerprints), but it ...


21

2FA alone does not help in this scenario. If the 2FA input screen on bank.com does not have other protections, like TLS, pinning/HSTS, MITM protection, and/or verify the client or detect login anomalies, then there is a vulnerability. This is a case where an integrated password manager in the browser can help the end-user, by not providing the credentials to ...


21

In addition to the issues with SS7, SMS is not meaningfully encrypted. Sometimes the last mile portion (between tower and device) is encrypted, but that encryption is weak and can be broken. Other times, even that layer of protection is absent. Furthermore, at lots of other points along the transmission process - including some that can be intercepted by ...


20

No. Biometrics never leave hardware-backed keystore (TEE). Apps use android Biometric API to authenticate the user. Biometric is verified by hardware-backed keystore which answers authentication result with success or failure to the API. As it's a system API, apps implicitly trust the authentication result. To ensure that it's not a fraudulent TEE verifying ...


20

You are not incorrect. That is why biometrics are not typically used as the sole factor in authentication. Biometrics, like fingerprints, are not secret in the first place Biometrics are weak authentication since biology changes, fingers get removed/scarred/burned/etc. Biometrics for authentication usually require some other biometric factor besides the ...


17

It sounds like the thing you're interested in here that's related to SSL and TLS is authenticity, although TLS also provides confidentiality and integrity. The latter two are difficult in standard telephone environments due to laws mandating the ability to wiretap calls. However, there are protocols for authenticity of caller ID information called STIR and ...


16

From a security perspective, you should not disclose to visitor, that an account under a given name already exists. By doing so, your users are prone to the account enumeration attack. Depending on the kind of your website, this may disclose unwanted associations for your users. Think Asley Madison, where users were exploited by testing their public email ...


16

The design flaw is not in the cryptographic binding between the prover (key) and verifier (car). It's in the communication channel. HOTP is a secure way to generate tokens but it doesn't secure the channel. HOTP can be only used in keyfob with remote locking/unlocking. NFC devices have an unfixable problem of relay attacks on which attacks against keyfobs ...


15

I don't see to how your proposal is better than existing client side hashing approaches, but I find it as more complex to implement than others. Unfortunately you don't describe a specific risk you are trying to access so I just assume the typical threats commonly seen. Man in the Middle attacker In this case it is assumed that some man in the middle has ...


15

To extent CBHacking's point, the privacy issue is not just for people using this to sign in (which can be considered acceptable since using the federated login can be optional/users can choose which provider to use) but sometimes even affect users who intentionnally avoid it. E.g. Google strongly recommends their client library which always sends ...


14

Security keys like yubikey, titankey, nitrokey, and solokey use the U2F protocol, which is immune to phishing by mixing the domain into the nonce. In order for this to happen, the attacker would have to have control of the domain. And if you're talking about a browser, they are configured to also require the page to be a valid HTTPS connection. Meaning the ...


14

Email is the least worst option. It's not just the ubiquity of email. Email is federated, standard protocol. No one entity controls email. Email is a marketplace. You choose your email provider. Don't trust them? Take your business elsewhere. There's thousands and, from an authentication perspective, they are all equivalent. You can even run your own service,...


14

Google's fingerprint HIDL implementation guidelines for vendors states: Raw fingerprint data or derivatives (for example, templates) must never be accessible from outside the sensor driver or TEE. If the hardware supports a TEE, hardware access must be limited to the TEE and protected by an SELinux policy. So no, your fingerprint data should never be ...


12

I can think of a few reasons: SSO means that it is the SSO provider that says who your users are. Technically they could deny legitimate users or impersonate them. Obviously there are legal barriers that prevent the providers from malicious use of this power but there is some risk in externalizing user authentication. A cryptocurrency exchange might also ...


10

The main reason might be neither, but the ability for conditional authentication steps. Some services e.g. support multiple single-sign on (SSO) providers, and the username is required to pick the correct SSO to forward the user to. Some may even have different authentication methods altogether. From security and privacy perspective this is also a bit ...


10

Password managers want to also manage OTP because they're in the business of making authentication easier. But there's a trade-off. Managing OTP (or any other truly additional factors) in the same place as your passwords shifts the risk model. It pools multiple independent factors into a single attack surface. This turns the system(s) running the password ...


10

PBKDF2, or for that matter, any password hashing algorithm, is designed to be tunable so it can take a variable amount of time, depending on the security level to be desired. The amount of time it takes will be constant assuming the same parameters are taken, whether the password is correct or incorrect, since it's impossible to determine whether it's ...


10

Would be bad form to ask "Why?" There are plenty of free, open source, battle-tested authentication systems in place. Unless you are expert in crypto engineering (and the fact that we are here shows otherwise), please don't invent your own system. It's great messing around with code just to teach yourself, but don't take it further.


10

Structurally, client and server certs are the same. Both will need keyUsage: digitalSignature and will contain the same type of RSA or ECDSA key. They chain to an intermediate and root CA via Issuer and AIA fields in exactly the same way as server certs. They handle revocation via CRL or OCSP in exactly the same way as server certs. However, depending on the ...


Only top voted, non community-wiki answers of a minimum length are eligible