I am working on a project where I need to design the logic for a Verified user. This means that a user (based on negative feedback) is not able to delete their account and start a new account under a different email id.
Currently, to create an account, a user enters :
desired userID,
email address (yahoo, gmail etc),
Address,
City,
State,
Zip,
Phone
How can I ensure if a user does close their account and start a new account, that the application can track this?
One option suggested was to send a secure code to the user's cell phone;
Unless they use the same details you can't. The only thing you can reliably compare is the e-mail address and everyone has several of these already and it's easy to get more.
You will have to be careful if you only allow one sign up per address as this will prevent members of the same family signing up to your service.
There's no reliable way of doing this, unfortunatelly. Unless, of course, you'd ask user for an SSN number and then validate it somehow.
Given that the combination of data you collect is open ended and their are virtually infinite possibilities for each value, I'm not sure you can prevent this, unless each user is tied to another device, such as a hardware key token or some other non user provided hardware based out of band authentication.
Related
I came across this post - Structuring user data by email address or by user ID. I am using a custom SQL backend where I use email Id to identify a user. As explained in this document - https://firebase.google.com/docs/auth/admin/verify-id-tokens I am verifying the Id token and extracting the email id, INSTEAD of UID. I don't see any real need for using the UID to identify a user. Any thoughts on why to use UID in my case?
Email addresses change over the lifetime of a user. Think of email addresses you had and don't use anymore, such as your email address in college, or the one with parts in it that would come across rather immature when you'd mail a potential employer from it.
If you think none of these apply to your use-case, you can of course use the email address as a unique identifier for the user. But in practice I've often seen developers revert from that over time.
Emails are changable in firebase authentication, a user can change their email id but never their user id, so it's better to use the user id, so no matter what the user changes they can always stay linked to their data.
Is it safe to share a user's ID that Firebase creates when a new user is created? I'd like to use it as an easy way to find other people on my platform.
I don't see why it should not be safe, so if it is. Please enlighten me :)
I am not too familiar with your system or how Nintendo does this (not really a gamer) but you can build something like this:
You can display the list of users (using uid, displayName and photoURL which can be obtained using the Admin SDK or by a list you maintain in the Firebase Database, Firestore, etc) to an authenticated user.
Let's say that user wants to add a connection or friend, you can get that user's ID token, the friend's uid and then add that user's uid to that authenticated user's pending connection list after you verify their ID token.
On the other end, you want the other user to accept the connection request (assuming this how your people finder feature works in your app). You would show the list of pending requests. When the user accepts the request, they would send their ID token and once that's verified, you can consider the connection completed.
To summarize, you still need an ID token to confirm the user sending the request and the one confirming it. Otherwise, if you just solely rely on uids, any user can get the uid of other users and try to add them to each other's friends list, etc.
Hopefully this points you in the right direction.
my friend and I were thinking of a Web idea and ran into an issue:
We can't allow the email address to be sitting in a database with its associated data, in the case of a hacker obtaining the database. We'd like to ensure the email address and its associated data can never be linked, but then on the other hand we also need to keep them linked somehow so we can send users email notifications E.T.C
Can anyone think or know of a way around this? (.NET, Umbraco)
Thanks!
Have 2 databases, one with users + data + user id, another with user id + email. Secure them both, if one gets discovered, the other one might not be.
In any case you are asking us to prove falsity. ^^
I can't think of a way to link user data with emails without actually linking user data with emails. However, it would be possible to not have the email address stored and linked in a database if you could live with only having their email address when the user is logged in.
You could require users to log in using their email address and password as many sites do, but you could store a one way hash of the email address (such as sha1(email+password) ) rather than the address itself. When the user logs in successfully, you can store their email address in their session without ever having to get it from the database. You could then send them emails until you destroy their session. This would prevent an attacker from connecting their data to their email without brute forcing the hashes or grabbing the session information from memory or user cookies depending on how you store it.
Unfortunately, this wouldn't allow you to send notification emails.
I'm starting to size up a project where I feel security needs strike a little closer to home. What tools and techniques could I look at to attempt to raise an alarm when a valid login is used, but the owner of the login has given it away or had it stolen. I would prefer ASP.NET, then MVC 3, oriented stuff.
This is not a silver bullet, but perhaps you should consider employing some kind of two-factor authentication. For example: when a user creates an account with you, you require that she provide you with a phone number where she can receive text messages as part of the registration process. Then, when she attempts to log in, you text her a temporary authentication code to be used in combination with her username and password.
This ads an extra layer of security to the system, because an attacker would have to both know her username and password and have physical access to her cell phone in order to compromise her account.
I hope that's helpful.
Seems like you would get a lot of false positives... but you might try checking what IP address the login is coming from. Most people will log in from the same IP address most of the time, so when that changes, it's at least a warning sign. If you want to be very strict about security, you could maintain a whitelist (for each account) and require that they get their IP address added to the whitelist before logging in.
My bank (Chase) does this by checking a secure cookie during my username/password login. If the cookie is missing or corrupted, they require a second form of authentication, which is either a code sent via text to my phone number on file or via email to my email address on file. Once the second form of authentication is complete, they set the secure cookie and then I can login from that browser with only username and password.
Implement your own Membership provider and add field locked to model,
check for user being locked on login and do some actions
It might be useful to think of the factors of the Authentication process, so that you can be sure that you are sufficiently covering things. You can easily get ridiculous with the layers of assurances, but I happen to find that most banks now have a variation on a simple model. All of this is, of course, over SSL
User submits account name. Additionally, you can require a secondary piece of information, last 4 of account number or year part of date of birth.
Optional, but a good idea: present the user with a counter sign, that is something that verifies the identity of the server. The user selects this at registration and should be looking for this every time they attempt to log in. This aids in preventing phishing.
System checks to see if the current system using IP lookup or cookie is associated with the account. If not, presents challenge question along with password input. Otherwise, presents just the password input.
Complicated, but can actually be done in 2 pages and more secure than is usually required.
I've presented this workflow to a few bank clients and they usually remove one or two of the checks for a balance of user friendliness.
With phones with text capabilities being so common, the idea of SMS verification code as mentioned by others is also a good idea, though I haven't implemented this in a system yet, personally.
I'm rewriting a website and going from a home-grown authentication model where users logged in with their account id (numbers) and password, to .NET FormsAuthentication where users will login with a username that they choose (or is available) and a stronger password. There are over 38K existing accounts and I'm trying to decide if the existing users should re-register or if I should write some code to do this on their behalf. I've already ruled out creating the usernames for the users because they won't be able to change their username. Luckily we don't have any users named Brenda Utthead.
If the user re-registers, some may gripe about having to do this step again and it may raise some support calls, but I stay with the standard process that everyone has to do. Or I can allow the user to login with their existing userid and password and then optionally give them a grace period to convert their account. I'm hesitant about the latter because it's special code and a possible threat vector because it bypasses the standard authentication mechanism and allows users to log in using less secure credentials.
This application currently accounts for about 40% of our website traffic and I'm not worried about users not coming back to the website because of the possibility of them having to re-register.
What does everyone think?
If you want your users to come back your best bet is to convert their accounts and send an email explaining the transition.
Do not make them re-register whatever you do.
You'll lose half of your users if you do that.
Give them a service so that they can enter their previous user id and have them provide their email address. Email them at the address provided and have them login with their email address as their new user name.
I am about to do the same thing. I am writing a migration page where the user logs in with his/her existing credentials and behind the scenes, I write out to the asp.net membership tables. Do a check first to make sure they haven't already migrated for all subsequent visits.
Don't make them re-register. A little work on your side is all it takes and you need to keep your customers happy.
After listening to everyone's suggestion, I've decided to modify the login. I look at the username they provide and try to guess that they're an existing user. Then I look them up in the old table and if I find a match take them to a conversion screen. There they can quickly convert their account or skip the whole process and login temporarily. The conversion form has fewer fields to fill out b/c I was able to authenticate them against the old user table so I don't need them to provide as much info.
I'm not thrilled with skipping the conversion but that option is only offered for the first 45 days from go-live.
Either convert them or find a way for both membership models to exist together, and somehow convert each user across at login or something.
Think about how long it took to get the 38k members and ask yourself if those were all wiped out, would those same people go through the hassle of signing up again. If you've got a really strong community you should be ok, the hit would just be a matter of time till you're built up.
The other thing you could do to mitigate the risk would be to send out a email, although spam blockers may filter them you could get to a high percentage of your users and tell them about the new membership stuff. Might get some older people back to the site as well in the process.
The biggest challenge is converting all the data that is associated with the user's accounts. People are going to be really upset if they've built up some sort of reputation that you're going to destroy with a new membership system.
This website is a check your balance type of website. It's not a banking site per se, but it exists as a convenience tool to users. I don't believe it would be realistic for users to cancel their accounts because they are forced to re-register.
I do like some of the ideas I'm reading in the responses though.
I would migrate their information and then on their first login ask them to confirm that their membership info is correct (just to be anal).