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.
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.
I would like to track anonymous user actions as if the user would be authenticated. The goal is to let users perform actions(normally reserved to authenticated users), save it in Database with a special status (not visible until user will log into the application).
For example,
an anonymous user reply to a comment.
The system detect that the user is not logged in, save the comment with special status 'waiting for authentication'.
The system ask user to log in, in order to complete the registration of the comment.
User log into the application.
The system check for 'waiting for authentication' status and update/associate entries to the user authenticated.
Have you any suggestions / experiences to implement this type of functionality? Maybe Symfony has already in feature/bundle for that?
What you are trying to do is simillar to Lazy Registration, which is a proven concept. It is well implemented here at stackoverflow. It allows you to post messages after providing an email address. It works similar to this one:
http://www.90percentofeverything.com/2009/03/16/signup-forms-must-die-heres-how-we-killed-ours/
However, if you really want to go your way, without asking user for an email address, I would recommend storing data at browser local storage. It would save you a lot of work on backend side. Data would be transferred to the backend only when user registers. This way you will also prevent database pollution with users who never registered. http://blog.teamtreehouse.com/storing-data-on-the-client-with-localstorage
You could use ip address but it won't be very effective because one user can access your website from many ip addresses (wifi, 3g/4g connection ...).
You can rely on cookies but once he logs in from another device you can't do anything about it.
IMO, you should save actions and link them to a uniq token that you send to the anonymous user, once he's authenticated he can provide the generated token and then you save actions for that user. Becareful to not forget removing saved anonymous-actions once they are "identified".
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.
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 have a simple web application set up where admins can create users. Users do not create themselves. All an admin has to do is enter a username and an e-mail and a temporary password is sent to the user for them to login. This e-mail is sent in plain text format. If the user is logging on for the first time, they are required to change their password and enter a security question and answer. The user obviously has to know their temporary password in order to login for the first time and this is the only way I know of letting them know (through e-mail). The other option would be to have the admin call the user and tell them over the phone or in person their temporary password, but this is not practical. How could I handle a situation like this?
I typically use a temporary url based on an invite record on the back end. Essentially you create an invite record and generate a hash based on some information perhaps the users email address, a timestamp and a random value. Store the hash as part of the invite record and then send them a url with the hash as the parameter.
When they click the link lookup the invite and validate that it exists and has not been used - then allow them to setup their password and invalidate the invite.
It gets rid of the need to send any sort of password and you can set an expiry on your invite records if you want as well.
The scenario you describe is very common- emailing a temporary password and requiring it to be changed on first login. Unless you have a specific problem with this model I see no reason not to use it. Having an admin call users can get complicated- I would avoid this at all costs.
You can generate a custom url with a password and user hash as argument where the user has to log itself. The hash will be difficult to retrieve if the attacker does not have the information