59

The primary attack method against text message OTP is to 'sim swap' and take over the target's phone number. If the site provided the full number in this scenario, they'd be giving the attacker exactly the information they need to break the security being used. (To lift up comments: In general, more personal information is needed, if you're going to social ...


32

tl/dr: One time recovery codes give account owners an option for regaining lost access. People who consider this an additional risk can always ignore it or destroy it, but people who are worried about losing access to critical services can certainly come up with a secure way to store it. As a result, it's a good option to have for services that may be ...


26

This is not about a "vulnerability". This is about personally identifiable information (PII). It's the same reason why credit cards numbers are not displayed in full on sites either. Anyone passing by your screen, cameras recording, etc, would see the info. And it's not necessary to show the whole number. It's just there as a reminder to the user.


14

If the full number were listed then I could visit your account, request a new password, and know your phone number. The last two digits are a tradeoff that permit you to know its (likely) your number without giving away your phone number to anybody who wants to view it on the website.


11

You probably could, but it doesn't make much sense. Email and even SMS can take long enough to reach people - even people who are explicitly checking for the message - that you'd need to check the last few minutes of codes, which broadens the range of allowable values and slightly increases the risk of an attacker guessing/brute-forcing the code. Meanwhile, ...


8

Well, the thing that all of us agree is that by showing the full phone number, the application is leaking sensitive information about the user. I don't know what regulation apply to your country however based on the GDPR European regulation phone number are considered as personal info an as such should be handled appropriately. This means that if the phone ...


7

This is certainly not normal. What it can do is protect the account from brute-force login attempts. An attacker will never know if a password is correct or not since they need the OTP from the email to be able to tell. However, this approach has its own problems. For instance, every brute force attempt will result in you getting an email. This can flood ...


7

Password recovery has always been a security weakness because the goal is to allow to make an action on a account without knowing the password. In controlled systems you had to go to the admin desk, tell him that you lost the password and let him shout that you were a stupid boy/girl. In the end, after confirming that you actually had a legitimate access, ...


5

Is a "magic link" a kind of authentication? Yes, it is. It authenticates the user, similarly to having them type a password, dip a smartcard and enter its PIN, or checking their fingerprint. It is not (inherently) authorization, since "clicking a link on an e-mail" doesn't necessarily attest anything. How safe it is to validate only the ...


4

Do you know those "Login with Facebook" and "Login with Gmail" buttons all around the web? They are almost the same. When you allow someone to login with their Facebook account, you are validating that the person have access to that Facebook account and in no way confirming his identity. That confirmation is being delegated to Facebook. A ...


3

No, this is not a back door A back door, in computer security, refers to a builtin mechanism for individuals who are authorized to access the system to continue to access the system after they are no longer authorized individuals who are not authorized to access the system but have some level of indirect control over the system (like, they wrote the code) ...


3

Would it not be more prudent to just generate a large ... string Yes, it would. A token is often a straightforward solution, and is easier to get right. Cryptographic solutions often have pitfalls or need to be implemented totally correct to be secure. Random tokens are more secure because they are simpler. JWTs are especially useful when having multiple ...


3

It's true that you can use a random string for the magic link and it'll work just fine. However there are a few benefits for choosing to implement it using JWTs: JWT validation doesn't require a call to the database. This is perhaps the main benefit of using JWTs at all. Depending on the number of users this can mean a significant performance difference. It ...


2

Homebrewed security is dangerous The thing you are describing already well developed with a multitude of publicly audited libraries and tools available for almost every web platform. A great place to start would be with oauth2. Even a service like auth0 might work, which would essentially be the "password server". The danger of doing this yourself ...


2

It doesn't matter how many mobile phones you have, each attempt still has 1 in 10000 chance of succeeding given a 4-digit PIN. What's important is how many attempts you have, which might not be tied only to a specific phone number but also to where the request ia coming from. This is one way to mitigate such attacks. Another is increasing the complexity of ...


2

I would argue that it depends on your specific case. Remember you need a client that will store the secret key (safely) and generate a TOTP. There are a lot of apps that do that already like Google Authenticator that you mentioned above. You could even create your own (although not recommended ). Most TOTP client apps give you 2 options to add a TOTP key ...


2

They do introduce a backdoor, but that's the whole point. How else is someone supposed to regain access to their account if the device they're using for 2FA fails? By contacting the account provider and asking nicely? We tried that and scammers love it. Recovery codes are the only practical solution to this problem. The only way to have perfect security is ...


2

what possible security flaws are there beyond having information phished, key logged, or copied in person Does one really need more problems on top of these? Basically it is asking to enter critical information into an untrusted third-party site. Untrusted means here both that one cannot trust the third party to not have shady intents nor that one can ...


2

Authentication with SAML uses password in the corporate directory. This password is one authentication factor. The TOTP uses key (password) that has nothing to do with password in the corporate directory. Thus these are two independent factors. For authentication an attacker will need to know both. Both factors are based on the knowledge of some secret. ...


2

As mentioned by @schroeder this is not a common design for two-factor authentication, but it could be used to increase the search space for the attacker who uses a brute-force approach. However, based on your description of how it works, particularly the fact that it gave you feedback saying that your password is incorrect, I think that the implementation of ...


2

Don't reinvent the wheel when there are very good and safe wheels available and you are not a Certified Wheel Engineer. You have a couple options to try before implementing your own. 1. OTP OTP is easy to use. There are already libraries for implementing them in a safe manner on Javascript (client and server side), Python, Perl, PHP, C, Java, and I guess it ...


1

Every classical authentication system with the functionality "I forgot my password, please send me an e-mail" is equivalent to the one you describe. It is simply authentication by proof of ownership of an e-mail address. Why not? The generated link contains an authentication token that can be limited to one use, like the authorization grant of ...


1

Tacking an additional layer of authentication onto a process generally isn't a bad idea, in and of itself. That having been said, I posit that you're not aware (as the SP) what steps that a user has already gone through to get to your application. What if they have already gone through a round of MFA on the IdP side? You're going to ask again, and that's ...


1

Online OTP systems, like sending code to a phone is secure because the attacker cannot know the code if he doesn't have the phone or can intercept the content of the message. And intercepting the message is easier than stealing a physical device. It can be done from another country, in a massive scale. SMS, for example, can be easily hijacked, either by SIM ...


1

You are trying to take something which is inherently online (sending and verifying an SMS OTP code) and make it offline. This is possible, but it will require great thought to do it correctly, and the approach you take will depend on your requirements (ie your question does not contain enough details to decide which is the best solution). I think the first ...


1

The idea is, once you've proven you have some "a thing you have" second factor (a phone number), you can basically turn your PC into another "thing you have" second factor. Since it's usually vastly easier to steal somebody's phone number than their PC, this is probably fine. It's done the same way any other long-term authentication ...


1

The potential problems with the "lost password" form are several. Some of those I'm aware of: It can be used to test / enumerate the accounts So my form says: "Enter the username or email for your account" and then "Thank you. If this data is in the database, an email will be sent. If you do not receive the email in a few minutes, it ...


1

Some systems do use alpha one time password. S/Key or the less old OpieKey are example of them For OTP systems using hardware calculators, the price of the hardware matters, and digital displays able to display only digits are cheaper than ones able to display letters The OTP is generally computed as a mere number (ie a sequence of bits). It can then be ...


1

RFC 6238 recommends “that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.” It doesn't recommend a resynchronization algorithm, although it does mention that one could be applied. In general, the way people usually handle this is to require the TOTP generator to have time ...


1

I see a couple of related points here that haven't been addressed: One-time master password complexity (weak - all numeric and short) Brute force / lockout attempts on 2FA. For 1) The weakness in length of these master 2FA codes, I agree, is a weakness. Especially if they are generated using a weak or known IV (initialization vector), or that gets leaked, ...


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