I am using the nodejs passwordless (https://passwordless.net/) library for passwordless login. One of the features is a link sent in an email that opens the logged in page in the browser. Works great.
What I would like to do is have it so that if the link is clicked on, on one device, and the page that the user entered their email is open on another device, then that page would also login, using some cookie or something.
The reason for this is to add even more convenience to the concept of passwordless login - by being able to click on the link on a phone you dont have to go to another tab in your browser on your computer.
Do people have any other thoughts about making passwordless login as seamless as possible?
What you're asking for isn't possible because it "begs the question" that authentication is designed to answer. Namely, "Is this client application operating on behalf of a user registered with this service?"
Let's walk it through:
Device 1
The user visits your website for the first time.
The service sets a cookie with the id of a new, unique session on your website (or app).
The user submits their email in a form.
The user receives an email with an URL+token, token courtesy of Passwordless.
The user clicks on the URL.
The service validates the token, again via Passwordless, and marks Device 1's session as authenticated.
The effect of this workflow (esp. steps 3-5) is to let you infer a vital piece of information: that whoever is contacting this website has control of the provided email address. Now let's look at another device.
Device 2
Some user visits your website for the first time.
The service sets a cookie with the id of a new, unique session on your website.
So we have a device, with a cookie, but now what? Literally anyone in the world could have just pointed a web browser or app at your site. We need more information. So we could ask for an email address:
The user submits their email in a form.
Now we have an email from Device 2. But we have no idea whether this is legitimately the user who controls this email address. It could easily be an attacker, someone after your service, after this user, or maybe just a spammer with some bots.
It's not until we get to step 6 in the original workflow that we have enough information to know whether this device is being used by the same user as on Device 1. But once we've gone that far, the user has just logged into Device 2! At that point there's no need to "log them in automatically" from Device 1 because they just authenticated themselves on Device 2.
I think this might be possible.
I don't have a cooked recipe but some direction for your exploration could be :
You need to set allow reuse tokens before setting your token store. This can be done by allowTokenReuse:true.
Somehow make sure first 2 or more devices gets the same session. This could be done by sharing sessions.
A more solid advice would be using sockets to track connected clients. You may want to check the post here
I found a awesome article to share and sync sessions between socket.io and express. Check here
Pls share your explorations of you can. I am thinking to use sockets aswell.
Related
I need this option to remember the device ID used when registering a new user and save it in the database, and later when logging in, if another device is used, the user needs to send a verification email to be able to log in to their account.
This is a similar feature as google uses for its Gmail.
If your application works on web than you can fetch the user-agent information and the user IP address and create a hash details using his combination. If the hash is different in the 2nd attempt of sign-in / login than you can do you desired action
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
I'm developing an web application using Django.
Currently I am working on sending "reset password link" thorough email (amazon simple email service - SES)
The mechanism I used, is the same with the answer of "simeonwillbanks" below link
Secure ways to reset password or to give old password
Give users a reset password option.
This option saves a unique token for a user. The token eventually expires (hours, day or days).
A link is emailed to the user which includes the token.
User clicks on the emailed link.
If the token exists and isn't expired, the link loads a new password form. If not, don't load the new password form.
Once the user sets a new password, delete the token and send the user a confirmation email.
What I worry about this, I am not sure this way is safe in terms of security. What if the email is captured by a hacker?
I tested on several major websites how they care this.
get an "reset password" email and copy the link.
give the link to other and see if he can change password on my account.
From this test, I figured out that somebody else also can change my password only with the link.
If I cannot do anything on the link, is there way to make email more secure?
like as the mechanism of ssl(https) on website?
Thanks!
It's somewhat secure, though is toast if the user's email was compromised.
I prefer using an HMAC in the URL, which avoids storing tokens in the DB.
If you include the user's IP address in the URL, and in the HMAC, you can be sure the reset link click came from the same computer (router actually) that requested the reset, and that it can't be shared.
Instead of the IP, you could set a device cookie with the username/email and an HMAC, and then check this when the reset link comes in from the email.
The system should ask the user the answer to a secret question after he clicks the link. Even better, send an SMS to his mobile with a short random code and ask for that. This is called https://en.wikipedia.org/wiki/Multi-factor_authentication
Then show the change password form (over HTTPS of course).
While we're here, you should display the same "success" message whether or not the user has an account, to avoid user enumeration attacks.
Also, use a localhost MTA relay or asynchronous email so that a hacker can't tell whether you sent an email (a slow response would indicate that a user exists).
I want to build a mobile app that requires the number of the user to be filled in. After that, the phone number is sent to a server, the server generates a random verification code that corresponds to this phone number. Then, this verification code is sent via SMS to the user. Next, the user sends the verification code back to the server to ensure that he/she has entered his/her real phone number and not anybody's else.
I was wondering how do you really authenticate against the server if you only have a phone number and nothing else? I mean, in the typical scenario you have a username and a password that are checked on the server and if both of them are correct you can have access to the server. But in the case of a phone-number registration, you have only a phone number and if you authenticate with it only, it means that anyone who knows your number or just picks it out, can pretend to be you.
If you send some sort of a unique device ID, that means that you won't be able to use your existing account anymore, for example, if you happen to change your device with a new one.
So, how do you solve this issue?
The pattern is always: client provides proof of something they have, in return they receive an identifying token. In a typical username/password scenario, this means the user proves that they have a secret (username + password), in return they'll typically receive a session cookie. In your case, the user proves that they are in possession of a specific phone, in return you give them a session token or other identifying token. The client holds on to this token and uses it to identify themselves to the server.
You're relying on the principles of the telephone system to make sure that's a uniquely identifying characteristic. You're basing your security on the assumption that only one person can receive messages for a specific phone number at any one time, and that you need to be in physical possession of the phone at the time of login to complete the proof. Of course you require this proof every time the user logs in. You do not let them register once with an SMS-loop, then afterwards you just ask them for their number and let them through.
If a user wishes to log in, they must proof they're in physical possession of the phone in question using the SMS-loop, then they'll receive a token. Period. That's the way it goes. No other way. The client (app) must hold on to the token for as long as it wishes to stay logged in. Obviously, you probably want this to last for quite a while and not require the user to do SMS confirmations all the time.
This obviously brings us to the topic of token theft, which can be a real issue. The token must be kept secret, since it essentially allows proof-less authentication. You may want to think about signing that token using some unique identifier specific to the device it's for, or encrypting it while it's stored on the device or other measures to make sure it can't be nicked from the device while it is stored on it.
As deceze points out, the best way to ensure the comm is safe is to use a temporal token signed with the device id. If the user logs out, changes device or reinstalls the app then they must go through the SMS verification process again to ensure the SIM cards is still in their possession. Keep in mind that the SIM card and device have different udids. To simplify this you can use RingCaptcha SDK on your app to generate the token, verify the user possesses the SIM card and store that token or id temporarily. Use the phone number as an identifier - similar to a username - and the temporal PIN code as the password. That pair plus the token will give you enough security that the device and SIM card are joined.
I am creating a j2me application for mcommerce, which uses mobile internet(gprs). I wanted make it more secured by binding the application to the SIM card and the device. That is a user should be able to login to the system, only using his/her SIM card or from the registered mobile number.
To achieve this I need to fetch the mobile number.
So, on login i thought of Triggering an SMS from the server with a key, which the application reads and uses the key for the entire session. Here the challenge is, that sms should not go to the inbox.
Any suggestions pls?
Yes it can be achieved using the Wireless Messaging API. Have the MIDlet set up a server connection on a chosen port number, then send the SMS to that port number. It will go straight to your app, bypassing the inbox. If you use the Push Registry, you can even make the SMS start your app if it is not running.
It doesn't matter if the user sees the number in his/her inbox.
As long as the key is only used that session, it is her/his responsibility to not share the key with others.
The one thing you make sure is that ONLY the person who owns the SMS phonenumber gets the key and is able to log on.
This doesn't take care of the phone being stolen though.