Ask HN: Why aren't one-time sign in links more popular for authentication?
Tying a OTP to an email appears to be more secure than the cluster that is remembering and managing passwords.
1. Email delivery latency: depending on the service you use, the time it takes to deliver emails to the user can vary. Worst case I encountered was up to 20 minutes delay when there were issues with Mailgun.
2. Usability: you have to leave your current app and switch to your mail client. You may be on a device where you don't have a mail client installed at all, so you have to provide a password login option as well.
3. The sign in dialog gets more complicated and it's hard to explain to users how it works as it is not all that common. This also had effects on sign up/sign in dialog design which we found to have a negative impact on conversion rates.
This usually happens because whatever service the site is using to handle sending out emails is under heavy load, having issues, or is rate limiting the site due to a sudden spike in logins.
If this happens for any reason, it failure cascades because the more people try to log in, the longer it will take for everyone to get a valid link.
At least with a standard TOTP token or the like, if the service is under load it will eventually work if you keep trying (versus not working for longer the more people try).
Hell this method also runs into the issue of getting flagged as spam or getting blacklisted due to ~~the algorithm~~ for one reason or another. This is doubly likely if a sudden burst of traffic to a site results in them sending out a mass wave of near identical emails.
Now non-tech users can't log in at all since they "never get the email at all".
Email is a wonderful thing but it is painfully fragile and doesn't handle time sensitive stuff well at scale (due to queuing, routing issues, and spam filters).
That is not completely true. I've been operating my own mail server for almost a decade, since I am the only person using it the volume of email I send out is almost none.
I've observed on more then one occasion that sending an email to my gmail or my fathers gmail account can sometimes take 20 minutes or more to show up in gmail inbox although I know that google accepted the email as soon as it was sent.
I'm not sure what all goes into ~~the algorithm~~ that google uses to decide to tarpit emails from a server but I'd make sure that you have your SPF, DKIM, and DMARC all set up properly to give google as little of an excuse to dislike your server as possible.
It's not a great solution but I've long since given up on any attempt at self-hosting email and just use my own domain with protonmail at this point since the industry seems to be so hostile to self-hosting.
I do have DKIM, strict SPF and DMARC policies, MTA-STS, SMTP TLS Reporting, latest TLS support and valid certificates, there is nothing else I can do on my end.
Actually, it could be either. Postmark (the email provider for a bunch of sites) monitors "time to inbox" for several user email services: https://status.postmarkapp.com/. Apple, in particular, seems to frequently add 2+ minute delays on the receiving end. (The "source" link above the charts describes how Postmark collects the data.)
As an email layman, I don’t fully buy this, can you explain? I’ve sent emails with multiple CC’s and most get it quick while one or two people have to wait for it to hit their inbox for multiple minutes. I assume they all leave my service at same time and the delay is caused by the receiving mail server.
The issue can occasionally be the user's email provider but for the most part issues with implementing one-time links will be the site's responsibility/a problem on their end.
As for email occasionally being super slow, Google and Microsoft (to a lesser extent) will tarpit(repeatedly delay the acceptance of emails from a specific address or entire domain) emails arbitrarily. This normally isn't anything meaningfully repeatable and is essentially ~~the algorithm~~ arbitrarily deciding it dislikes some certain email, email address, or server. Those emails will eventually get to their recipient but effectively get frozen in time for a bit before getting delivered.
For normal person to person emails, this boils down to bad luck and occasional inconvenience however for any heavily templated email (like say an email containing one-time links), this means something on the site's side is causing the emails to appear as spam or spam-like to the recipient server. So technically it is the user's email server causing the delay but it's usually due to something in particular on the site's side be it a domain or server configuration or something about the email contents.
On business systems, sometimes DLP rules impact delivery times.
I mean, when you send batches of mails to gmail, it lets them through first, then depending on its whim it starts throttling or outright blocking them.
Once in a while, it changes its handling of DKIM or SPF or god knows what and the only thing you can expect from them is an SMTP error message.
As an extension to your second point, sometimes I want to login to a service on a shared/public computer out of necessity. I'd really not want to login into my email on said computer too.
They did a nice job on that one.
However, the problem is that this goes so much against user expectations it just confuses people and they end up going through the grueling version of typing the long link in by hand in VR since they can't imagine it could be as easy as opening it on their phone. (We of course, call this out in the prompt, but nobody reads that.)
Why were clear terms like login/register/logout replaced with a “sign ...”? I get confused twice a week by these, especially because the difference between “in” and “up” is so subtle (and overloaded, like “sign up for a meeting at friday”, unrelated to registration routine). Sorry for offtopic, but it is really annoying. Is it more linguistically correct or just a hipster thing?
To "register" your interest in an something, you might sign a piece of paper, or instruct a person to "sign [you] up".
To show that you entered a physical event, you would sign an entry log on a piece of paper, then having "logged in" or "signed in", and then do the opposite on your way out.
Similarly you might refer to reproducing your physical signature as having "authenticated" yourself, if there's something to compare it to.
What makes one particular set of terms the right set given the apparent origins?
Sometimes literally that, with an ellipsis hiding the part that would otherwise distinguish between alternatives, so you just have to click and guess.
Are you not registering yourself for the single meeting? Adding yourself to the list?
This is particularly true when the recipient has enabled Greylisting[0] and delivery has to be attempted multiple times (which is perfectly fine from the point of view of the RFC standards). In view of this, email delivery rather resembles real-world postal package delivery (and not so much the instantaneous delivery of, say, phone calls).
So you either need to whitelist Amazon SES (and possibly a few other providers behaving similarly), or use a greylisting implementation which doesn't match the full IP (I think Mailcow by default e.g. uses /19 for matching IPv4 addresses).
A previous mail hoster of mine did the former, i.e. Greylisting based on the full IP, and what was even worse, their support staff totally denied any knowledge of it and tried to claim it wasn't their fault that any e-mails from Amazon (Amazon itself and anything using SES) would arrive with random amounts of large delay.
But email does has many uncertainty like spam detection and others to slow the process after SMTP server receive it.
Aside from that being spam, it's also likely to get legit emails stuck in spam filters as people start marking them as spam.
Secondly, I think most of the largest providers don't really grey list any longer. They seem to have moved to inbound throttling. So your first email goes through but then if you send a rash of mail, you end up seeing the throttle on the back side.
Greylist is allow/block based on sender IP, not receiving metadata, so I guess pre-send mail from the IP might help, but yes, other rules might slow down.
Long connection with inactivity get tagged, scored and disconnected.
Connecting without sending an email leaves you in the grey list queue.
There is to my knowledge not a great way to pre-warm for grey-listing
* Solution to this is to pay $$ / month to get a dedicated IP address, then never let it get added to a spam list.
They also randomly rotate through their mail servers on each retry attempt, so a simple Greylisting implementation based on matching the full IP address can delay your emails for not just one retry interval, but several (until by chance Amazon happens to reuse the IP of the original delivery attempt).
A smaller email provider can give you a shared IP that has other users and is therefore already whitelisted. Provided the email provider has good anti-spam approaches (e.g. enforced DKIM verification), you should have better luck with that shared IP over a dedicated one if you only send a few thousand emails a month.
I still contend that a dedicated IP is superior for deliverability reputation as long as you are sending enough email. For a brand new (to you) dedicated IP, it will need to be warmed up (gradually increase the amount of traffic it sends). There are automated and manual processes to accomplish that, including "pre-warmed" dedicated IPs that were previously in a "good enough" shared pool.
I initially thought it was a "problem solved" thing by paying the money. Ended up causing us regular work (not much, but still).
4. Some email clients still break links in emails
5. Proper links require HTML; otherwise you rely on the email client recognizing a URL as such (which brings us back to 4).
6. The email might mistakenly get recognized as spam.
But I think authentication in general is a problem which really needs to be solved, and in a standards-based way. For instance, with connecting to public wifi networks (i.e. at an airport), it's absurd to have to go through a web page every time to log in. Also with the proliferation of IoT devices, it's always painful to go through the process of connecting it to my bluetooth and/or wifi. There should be some kind way to handle trust systematically through my smartphone without having to manually type a bunch of passwords.
1. There is a dependency on speed of email delivery. May be use SMS as well?
2. Personally, I didn't find it too difficult. We run into same issue if we have MFA
3. fast.co experience is pretty clean. Give it a try
Disclaimer: I am not affiliated with fast.co
Super frustrating, and something Apple should clamp down on (any app that opens web links needs to provide a full “open in Safari” option that isn’t an in-app browser).
With traditional password reset by email, at least when I try to login next, my password won't work and I'll know something might be up and can change my email password.
Source: I work for SparkPost and we do all of the above.
There’s one service that I literally can’t log in to because the link has always expired by the time I receive it.
E-mail is NOT INSTANTANEOUS. It was never meant to be. It happens to arrive quickly for most people most of the time, but you should never, ever, base a service on that.
Many systems have greylisting in place: a new sender gets a 4xx reply, and is allowed through only on subsequent retries after a pre-set time period. This is often as much as 30-60 minutes. It's a good approach to reduce spam, it turns out a lot of spamming software does not bother to retry, or doesn't want to incur the cost.
So, if you try this OTP-over-Email approach, you end up with frustrated customers, who 1) have to wait up to 60 minutes, 2) their OTP doesn't work, because you expired it after 5 minutes.
It's terrible. Don't do it.
Usually I can request a new login (or email verification) link and it will go through immediately. It does not work with Sendgrid-based services though, as Sendgrid rotates the IP used by the service for every mail.
I actual was astonished by the simplicity of sign in links when for the first time using gather.town . I have seen then also in banking (revolute) with IP address pinning which proved to be annoying because this randomly switched depending on network availability.
And now formerly G Suite, as it's become Google Workspace. Gotta keep that "products rebranded per decade" quota up, it seems!
Joking aside, email never coming is a pretty common occurence for me on new services, especially small orgs (local clubs, small merchants)
Mail servers do not even have to be on the internet (https://en.wikipedia.org/wiki/Non-Internet_email_address), or on a network at all. It was fairly normal to have a time sharing system dial in to a mail server every day for a few minutes to exchange mail messages (https://en.wikipedia.org/wiki/UUCP#Mail_routing))
Also, of course, it is harder to accomplish in a decentralized system that isn’t controlled by a single party.
Just increase the time? 30 mins will do. Especially if it's only one time use.
By the time I finally get to my email, the link is expired and I just give up.
Consequently, I almost never use that service.
With password managers built into all modern browsers, casual users (which, lets be honest here, are by far the most of the web users) do not have to worry about typing passwords. Security be damned. If it is not invisible to the user, they will reject it.
The Achille's heel of password managers is if someone accesses your computer (physically or remotely) they can probably access all your accounts. <-- and I've seen this happen (not to me)
The Achilles heel you mention matters very little since it is a very rare threat model and it would be unreliable to assume that access ends at some point rather than that the adversary simply installed some persistent malware to read all future passwords.
I agree, but perhaps password managers aren't a one-size-fits-all solution. People in high risk situations (e.g., admin @ crypto companies) that are likely to be specifically targeted, might be better served without a password manager. But yes, if RDP, e.g., is left on and open then a keylogger could be installed anyways...
It's -vastly- better for casual users to have secure, single-use passwords instead of what most casual people do: have 1-2 insecure passwords with variations. Thus allowing any phisher to get access to everything anyways.
Just because something isn't perfect doesn't mean it is not an improvement.
Imagine that.
Also, having such a critical part of your system depend on email delivery and access? Looking at most frontend development practices I understand the blindside/YOLO attitude these days but it's still a bad idea anytime of the day.
1) Something you know (e.g. a password)
2) Something you have (e.g. a token)
3) Something you are (usually biometric authrentication, like your fingerprint, a retina scan...)
Real OTPs fall in the second category, because you have some device/application that is able to generate the same OTP code as the server handling authentication without communicating with the server. Now there are some popular solutions that are still being called OTPs that instead of something you have is something that is sent to you, like SMS OTP. This isn't just quibbling, because sending something each time authentication is needed, opens up the possibility for some attacks that wouldn't be possible with proper OTPs, e.g. SIM swapping. So to answer you question:
- Just having to click on a link sent via email has the problems outlined in other comments
- having to both enter a password and having a link sent to your email address is safer than just enter a password, but
- having a true OTP, like the TOTP standard, is what provides the best security (in the category of OTPs, I'm not talking about protocols like FIDO2 and similar, because I don't know them).
EDIT: formatting
Doesn't this mean that a system which relies on an token sent to you is no worse that a system with a password? With a password, you can guess that GTP used the same password on Hacker News and BigBank, and if that fails, you can try and have their token redirected to you. Without a password, you have to rely on getting that token. So if your argument is that email and SMS are insecure channels, I mean yeah okay; but it doesn't make a system more secure if you can get in with a password _or_ an email/SMS vs the only option is an email/SMS.
I hate passwords; my password manager (the one built into Firefox) will generate passwords on my desktop, but most of the time I need to generate a password it's on my phone (where, oddly, they have not included the capacity to generate a password). So my password is crap, perhaps not stored, and I forget it. I rely entirely on the password reset facility. But most of the time if you tell me "please just sign up, think of a unique username and a secure password" I'm just not going to bother.
A nice middle ground would be allowing to opt out of passwords, for people who are happy with the combination of device token plus email OTP. This would work even better if device tokens were not binned with all those junk cookies: I think it could be valuable to have a class of "qualified cookies" that can only be written on user prompt and have reads optionally protected by additional local authentication requirements (configured on the user prompt), basically something that sits right in the middle between the streaming heap of cookies a browser stores and the browser's password store that allegedly nobody uses. I believe that this could be a major win for web privacy, "delete all cookies except for those which the store considered important enough to depend on a user prompt" (obviously, the client needs to include a "pretend to store, but actually keep only for the session" option to prevent abuse)
You could almost implement this for a site already using the web storage API, except for the unclear client prompts and lack of fine-grained tying into additional client side authentication measures (e.g. like how you might want a password manager to maintain very different master key freshness requirements for different entries)
That's a general response to the question of why passwords might be nicer than email OTP.
But it doesn't answer my question - namely, any security problems that might be attributed to email/SMS OTP also exist almost invariably with almost all in-the-wild password implementations, and therefore, isn't email OTP only more secure than password plus an email OTP called "password reset". This question is purely a rebuttal of the claim that passwords are more secure than email/SMS OTP.
In the wild, there are a few sites where an email account, and therefore password reset, is optional. Hacker News and Reddit are examples. But these are in the extreme minority, and almost never secure anything worth securing. Bank accounts are another class of exceptions, where they secure something so valuable it is worthwhile going through a human verification process before you can do a password reset. But almost everything else - online stores, newspaper comment columns, much social media, web apps used for work, phone apps that let you monitor your robot vacuum cleaner, email accounts - almost all of them expect you to have an email address and use it for a password reset
Regarding your problems, it sounds like you're in need of a better password manager. I personally use LastPass. I'm not saying it's the best out there but I've been using it for a few years and haven't felt the need to jump ship yet. The advantage of having a 3rd party password manage is that it can run on your phone, tablet, laptop and any browsers you want.
SITE="www.example.com"
SALT="passphrase"
printf "${SALT}${SITE}" | shasum -a 512 | base64 | cut -c -25
This will generate a non-reversible password with an entropy of 25^64 but it is re-creatable on any system that can display a web page and the password is not stored anywhere (so it's firmly "something you know"). If the password becomes compromised then you change your salt and a new unique password will be generated. Thus you only need to memorise a small subset of salts rather than a password per site.
This was how I used to do passwords several years ago before I gave into the convenience of password managers.
I've always considered them to be more like user names, albeit with a larger entropy than your average user string.
Completely agree with your points though. Particularly with regards to OTP. I'd further expand on that and say hosting your TOTP codes in the same password management tool as your passwords themselves (as some tools are now offering) is also really bad idea.
I won't try the one-time-link approach again unless the app's specific use case makes passwords extra painful.
Related, I've consulted for a company that downloads and caches every link in every email passing through their corporate server.
1. Browser visits a site that needs authentication. 2. Browser checks if there's already an existing client cert. 3. If not, browser generates one. 4. Browser uses it in the SSL handshake, resulting in the user being signed in without passwords, cookies, email links, etc.
My day job occasionally involves a WebDAV server protected with a normal login plus a client certificate. Sometimes I need to explain the process to less technically literate people who use different client software than I do, and the certificate part is a total pain.
Because, although everyone understands passwords, they have security and customer experience issues:
- Users choose easily guessed passwords and get hacked.
- They use the same passwords on multiple services and get hacked.
- They forget passwords, requiring an email reset, so they need to access their email anyway.
- The service doesn't need to store and manage passwords.
Every authentication method involves tradeoffs, and the service has to decide which set of tradeoffs they prefer. Personally, I prefer passwordless logins, but I understand why they're annoying for some.
Compared to passwords in terms of security: you have to consider that the client visiting the link might not be the client with the session being authenticated, at which point there might be confusion over multiple authentication requests of mixed legitimacy around the same time. I don’t know how this is typically solved.
I think better than either for security and usability is passwordless WebAuthn with a local factor (e.g. Touch ID for Apple devices, or even a master password for a simple improvement over existing password-unlockable saved passwords), if implementing something outside the status quo.
(edit: starbugs’s point about latency is also very important.)
https://www.w3.org/TR/capability-urls/
There are some problems though and the authentication could be called weak.
Problems is that URLs aren't regarded as secret and the irrational tendency to log everything doesn't help, as these OTP will be visible after a while.
So these OTP have to be invalidated at some point as they tend to become revealed. If expiration is necessary, you still need some form of auth to regain access.
OTP login is multiple steps, involves me doing a copy/paste (or remembering the code), and requires a mandatory delay while I wait on the email. If I wanted to login incognito, or in a different browser, I may have to copy/paste the URL etc.
A better question is why anyone uses them at all given how bad they are. I've stopped using at least one site because it exclusively uses OTP links.
For example, I've been locked out of my Patreon account for the last couple of weeks since Gmail decided to return 550 errors (address doesn't exist) [1] and they require an email to log in when the IP address changes. Most likely my email address has been added to the suppression/bounce list of Mailgun.
Working in IT with a direct day-to-day relationship with end users, passwords are the bane of all existence.
You say email delivery or sms is slow, but how often is it slow for users? Data on this? I personally have never seen a significant delay for an OTP code to either my inbox or my email (Google & Verizon). I have seen users that have an old email configured that is no longer active, but, oh, 80% of the time their cell number is a backup, so resolution is easy enough for them.
You say it’s insecure? Really? So the more than 30% of your users that have their password written either on paper on their desk (most commonly a sticky note or in a small notebook just hanging out on the paper pile) or in an unencrypted note taking app is somehow more secure?
You say it’s inconvenient? What? It can’t be more inconvenient than having to go through a password reset process once a week (which believe it or not, a TON of end users do).
Is any one actually measuring this or is this as an complete echo chamber of nerds that are good with password managers? Because I can tell you with certainty there’s a whole demographic, generation of humans out there where single token logins (backed up by multiple OTP at certain time or event trigger intervals) is BY FAR AND AWAY A BETTER WAY!
You want an example of who I think has this perfected: Affirm.com
That is what I do with many services I use. I ask a reset password link every time I use them. I then just copy paste a random passphrase as new password and forget about it.
Security and comfort are sometimes at opposing ends.
1) it’s unreasonable to expect people to remember so many passwords. I forget passwords all the time. Password manager isn’t that great since it doesn’t work cross device. 2) even with OTP, email is slow. Also email can distract and adds friction 3) federated auth such as google/GitHub auth is great. I usually get in in a single click.
I’d say if you want to prioritize you prolly get the best bang for buck in following order
1) federated auth - no need to store passwords, no forgot password flows. It assumes your audience is okay with google/GitHub/Twitter etc auth and has an account in one of the services.
2) email/pwd. More complications but benefit is it depends on no 3rd party.
3) one time link in email. The benefit is user doesn’t need to remember password. It does depend on email which adds some friction.
Note: you can have all 3 options and let user choose for maximum conversation. The tradeoff is more work on your side.
Life is all about tradeoffs. No one right or wrong solution.
See https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/... for more information on how cutting hairs on latency can dramatically affect an application's adoption rate
I still like the OTP process, but it is more hassle than using the password manager.
If your login mechanism sets a cookie after they verify the link then they can continue to be logged in for 3 months or however long you want. This is similar to what you would do with a password.
Also the site type and your audience makes a big difference. I wouldn't do it on a site where folks aren't technical.
But for example what about an ecommerce site where customers need to register an account + put in credit card details to place an order and then they get access to digital goods?
In the above case the lack of password is a benefit because it simplifies the payment form. Now they only need to put in an email address + card details.
And for getting access to what they purchased a slight delay isn't the end of the world. You could even give them access to it immediately in some type of unverified way (limited features until they verify). Also it's a slight deterrent for account sharing.
Any link that ends up in a browser address bar should be treated as public.
And no, it doesn't matter if you use HTTPS. Ways to leak it are many, but the gist is that it's treated as "meta-data" and, rightly or wrongly, subject to much lower expectations of privacy. A recent scandal was that several common browser extensions collect this meta-data and sell it to marketing companies.
Which marketing companies offer searchable subscriptions (for hefty prices, true, this isn't a $9.99 service), where somebody could for example search for "yourcompany.com", or even worse, "yourcompany.com/authernticate?token=". Yeah, meta-data.
Then I noticed that some of the text was wrapped in a tokenised link to the platform managing our reviews, bypassing the login screen. Support said they could not revoke these tokens. We had to close the entire account and migrate everything.
Regrettably, the issues with passwordless email/SMS login mean that for now, if there's no OAuth provider you can/want to use, the ol' password is probably still the best way to go.
I am surprised to see that so many people have issues with email delivery. Though email delivery can be delayed and in theory there are no guarantees.
Have you considered using SMS or a 2FA App like Duo? They should be near instantaneous.
The idea of sending this over telegram or signal is a good approach though the costs of Whatsapp messaging would be prohibitive. Even SMS will not work at scale. So really boils down to 2 things
(1) Speed - can you service live with delays or provide an alternate? (2) Cost - this cannot be tied to the per message cost like transactional or promotional email/SMS. A different pricing model help.
[1] - https://notion.so
I see passwords as reducing security (we have a low-security product so people can reset with an email, so security-wise, the upper bound is your email security), hence we used it. But people prefer the "remember the secret" shortcut!
Nah, just let a password manager handle it.
email is still mostly sent as plain text over the internet, that's certainly a downside.
email delays haven't been a problem in practice for us.
we also send users notification emails with links going directly to the right page, automatically logging the user in. i would like that from other services as well, as i'm browsing with ephemeral browser containers. having a clean browser environment triggers some website (eg github) to verify my login with a unique code sent by email. that indicates email delays aren't a showstopper in practice at big scale either.
Opportunistic TLS for SMTP seems to have been dominant on the US portion of the internet for nearly a decade. Especially as email is concentrated in a few huge providers who have been using STARTTLS for many years.
I say this based on the systems and logs I have monitored in that same timeframe. In fact, many email systems (mostly corporate MS Exchange) appear to be configured to reject or spam-bucket email connections that don’t support STARTTLS with a public CA certificate. (This observation may be biased by covering the financial services industry more than others.)
For example, some time ago made a Slack bot with a web dashboard. The authentication method was based on introducing your Slack username and the bot would send you an OTP. The latency problem didn’t exist here.
Wonder what the impact of that has on both of them?
Finally, if you ever loose your email password, you won't be able to access any of your accounts anymore...
Where email appears as a push notification on an imap idle configured email account, email can be far more unreliable, even with the best transactional email services.
What about a use case when it is inconvenient to create another password for a new user base at a company and this way you have users without calling support all the time.
Many companies in China use this way. does there have any possible exploit/disadvantage of this method?
* requires app: This is the main killer. I'm not going to install some random SaaS vendor's app on my phone just so I can log in
* requires internet access on phone: sucks if your phone doesn't data, cell reception is spotty, or wifi isn't set up
* less phishing resistance: one time sign in links are impossible to phish, and passwords have mitigations that protect against phishing (eg. password managers that only auto-fill on the correct domain) and users are generally aware to "check the address bar before entering password". scanning a QR code has neither of these.
P.S. authenticators have their own problems too just like E-mail. :D
No complaints with it.
Everyone has an HSM in their pocket these days. The fact that we are having these discussions at all is ridiculous.
If you refer to the typical smartphone, it's an HSM without the Security, and also it's not truly Hardware.
Unfortunately that also means that if I click the link by mistake the bad actor now has full access to my account. All just a misclick away.
Doesn’t clicking the link set cookies in your browser that then authenticate your session? How would you clicking the link somewhere give access to an attacker?
Some of them recognise that users aren't always signing in on the same device that their email account is set up on, so the link in the email just confirms that the login attempt is genuine.
This is similar to how Google/Apple/Microsoft/Blizzard/Steam handle login requests with their respective authenticator apps. You attempt to log in on device X (which can be anything), then confirm that the login request is genuine on device Y (your personal device).