How to prevent MITM attack while setting password using activation link - javascript

I am sending activation link throught email id which inturn is calling after creating user.These are the steps that I am doing:
Create User Without Credentials.(OKTA API)
Activating user with send email set as false.(OKTA API)
Through my own code I am sending activation link to the user.
After he clicks on activation link it comes to my custom page .
After he enters password when he clicks on submit SET Password of OKTA API is fired and the user becomes activated.
The problem with this approach is this to not able to avoid MITM attack, as if someone gets access to user email he will be able to set his credentials.
What is the best way to avoid this?

Related

Find and redirect to appropriate email client based on email address

I want to add a confirm email address link similar to what trello does. Based on which email client you use I want to redirect user to appropriate url.
For example:
If a user has example#gmail.com then the link should open mail.google.com.
If the User has example#outlook.com it should open outlook's link.
Moreover, if an user has their company's email address and they uses gmail as their email client, I want to find their email client and try to redirect there. This could reduce the friction where user need to manually navigate to their email client to check and confirm their email.
Is there any simpler way we could achieve this?

How to implement firebase email link authentication in chrome extension?

I want to send email link to user's email to authenticate user in my extension. How to automatically detect when the user clicked the link in email?
I've configured up to sending email. But my problem is extension popup still shows login form even after user clicked the link.
I'm using React.
How to automatically provision the access to user after he has clicked the email link?
How to automatically detect when the user clicked the link in email?
Firebase will log user on the device on which they clicked the link. Even if it's the same device, it'll most probably in a different tab. Easiest thing to do would be using Firebase Realtime Database.
When use enters email, send the sign in link and listen on a particular node in relatime database.
When use clicks on that link and is redirected to any page after login, update the value that node in RTDB.
When the update is received, do the changes required.
However this won't work is user uses the link on a completely different device so a custom solution might be needed.

Is there a way to verify email without also confirming account status for a user within a user pool in AWS Cognito?

I'm setting up a web application and want to use AWS Cognito to handle the user authentication portion.
This is the flow that I want.
New end user visits web app and clicks Sign Up.
End user enters email and password and clicks Create Account.
User sees message on screen "Email has been sent to your account. Please confirm email."
User goes to email, sees the new email from AWS. Inside there's a link. User clicks the link.
New page opens up with message "Email has been verified. An admin will review your account and an email will be sent to your account when it's ready."
Admin sees that a new user created an account and needs to be approved (on some dashboard).
Admin accepts the user.
User gets an email letting he/her know that the account is ready for login.
My problem happens at step 5. This is because the link that AWS Cognito creates and sends in the email to the user simultaneously verifies AND the confirms the account. Please see the picture below of what actually happens when the user clicks the link.
In the screenshot table above, user_one is the result of the user doing steps 1-3. Meanwhile, user_two is the result of the user completing step 4.
Now the problem with this is that user_two doesn't need an admin to confirm his/her account since that link did it automatically.
What I would like to know is how to JUST verify the email and NOT simultaneously confirm account. That way, I can actually implement steps 5-8.

How to check a web page request came from user inbox

I have a web application which sends a download link to subscribers. Subscribers are able to click the link from their inbox and get access to download a pdf document. It is fine but what I want is to allow the access to pdf document only when link is clicked from his inbox only. I mean if subscriber forwards this email to some one else or tries to paste the link in browser manually it should not work.
What you want is impossible.
Consider this situation: You email someone#example.com. They can view the email via:
a) Desktop mail client
b) Smartphone/tablet mail client
c) Webmail
All three will appear "different" to your server, depending on exactly which client they clicked on your link in. And if the user forwards the email to someone else, say otherperson#example.com, the EXACT same link will be in that person's mail file as well, and they can view it via the exact same options.
You MIGHT be able to extract a username or some other personally identifiable datum from the refer IF they used webmail and the webmail system is stupid enough to have webmail.example.com/readmail?userid=someone
But otherwise, no, you cannot assume anything about the incoming click, only that SOMEONE clicked on the link in SOME email.
There is no way to tell if a link was opened from an email client or if it was pasted into the address bar. There is no way to track if an email has been forwarded (webbug images in an HTML formatted email are blocked by most email clients).
If you want to limit who can download the file from your servers, then require that users login and then hope that none of them engage is password sharing.
Even that won't stop them redistributing the file directly.
Its not really possible to "protect" a link.
But if your web application require user to login, you can generate a unique link for each of your user, and require him to login before allowing download.
People will be less prone to share their login/password than a simple url.
I know this is an old question and I'm not sure why it was down-voted, but an idea occurred to me. If you put a common pixel tracker in your email with a token that identified the user and the email edition which, when requested, your server would note the time the email was opened and read (and successive reads). Then if the user clicks the link in the email, a token on the link identifies the same user and email edition. When the server receives this request it could compare it to the last time the matching tracking pixel was accessed. If the pixel was accessed within a few minutes before the link was requested, that implies that the email was opened and then the link was clicked.
If the user book marks the link and uses it the next day, there would be no recent tracking pixel history, which implies that the request was not from the inbox.
This would be easy to spoof, so it shouldn't be used for any kind of security concern. You wouldn't know if the email was forwarded to another person. Their email client would hit the tracking pixel as well.
Many email clients would block the pixel tracking for ever-increasing privacy concerns, so it isn't reliable.
If you're just looking for an indication of usage, this might work.

Return signed document or link to signed document in docusignapi after signing process completion

I'm able to login and Get the Embedded Signing View which will return a URL where given user can review the document and sign on it. now we've got the url, user signed it and we redirected it to our application's home page. but how can user see the signed document.
I wanted to send Email to both user and owner after signing process completion with access credentials or URL to see whether document has been signed or not.(I know owner will receive an email with link and subject which says that user has viewed the document)
but how can a user(who just signed the document) see the signed document
(may be this is a silly or dumb question but I'm really not able to find-out any way)
I'm using embeded signing(REST v2).
Generally in your pattern/use case you would have email notifications turned off for embedded signers and use. But there are a couple ways to get the signer back to the signed document:
You can turn notifications on completion back on if you wish to send a completion email to the signer. You can review this guide to assist you in the right setting https://www.docusign.com/support/how-to-guides/sending-and-signing-options
Create a DocuSign connect listener and have DocuSign connect send your listener the
completed document and your site send an email to the signer with a
link to your site to retrieve your stored copy
Create a view button that requests another recipient view for the signer so they can
access the document again just like you did for them to sign

Categories

Resources