Let's say I have a table of food items to bring to a lunch on a very simple web page. I don't want there to be login, but I would like there to be some smartness to my app.
Let's say a user puts in a food item. Other than a login, couldn't I use the IP address to do things like: only the user that created the record at same IP address can edit this record. Something like that.
I was thinking one more step toward a login, have a single text box where a user can put initials.
This way first person to suggest bring an item can be happy to know their todo for the lunch is done and can't be "overwritten"
That's it!
Pros and cons, welcomed!
This is more of a helper app than a formal thing, like to help around the office of local users.
Authentication and Authorization are separate functions, and I'm drawing the distinction here for a reason.
Authentication is the process of positively identifying a user, so you know who they are.
Authorization is the process of allowing or preventing that user from accessing parts of the application.
IP addresses can be used to partially identify users, but as #Dai pointed out in his comment, it has problems. Even using a Mac address is problematic since some people know how to spoof Mac addresses. If you can use someone else's authentication service, you can authorize them yourself.
Once you have positively identified a user, you can track them using a randomly generated ID that is good for a session. It is possible to use a cookie to track that ID. If that ID is associated with a Role you can authorize based on that role.
Related
Maybe I am missing something here, or this is a flaw in Auth0? I'll give an example of my issue:
Let's say I have my Default App (client), hooked up to that I have Username-Password-Authentication (database connection) and google-oauth2 (social connection).
A user comes to my site, signs up via google-oauth2 (social connection) using joe#gmail.com. Once complete, he gets added to my users in Auth0, all great.
A few months later, Joe comes back to my site, and being a busy guy, he forgets he signed up to my site before. This time, he decides to sign up using my custom Email and Password form, that will add the user to the Username-Password-Authentication (database connection). so he signs up there using joe#gmail.com again, and everything goes well, he is now listed in my user's section in my Auth0 dashboard.
This is the problem, I now have two joe#gmail.com accounts, one with google-outh2 and one with Username-Password-Authentication. I really can't have this, I need a unique email address, regardless of the ID Auth0 supplies.
Does anyone know how I can make email address in my user section 100% unique? I'd think a rule would do this, but it appears rules only apply AFTER a user has been registered, so I can't run a rule before adding?
the only way I can see doing this right now is make my own checks and delete via the management API, but that is a really long and messy way to do it I feel.
Any help will be appreciated here!
Thanks!
Auth0's default behavior is to create a new account in the database for every unique entry. Since the user created using Google has a unique id (based on google-oauth2), and the user created using the sign-up form has a unique id - they will technically be considered two separate accounts. In order to resolve this disparity, you can establish a means with which the account data can be merged. In the documentation linked provided above, there are examples of three possible ways of doing this:
Automatic Linking - which involves creating a specific rule to merge users based on matching emails
User-Initiated Linking - which involves providing a UI for users to opt into merging users with matching emails
Suggested Account Linking - which involves setting up a rule that is linked into the UI
One important thing to consider is that the data returned from different social identity providers may not be normalized the way that data is normalized onto the Username-Password-Database. For example, while auth0's default for emails is to lowercase the information, google-oauth2 may return emails as Uppercased - creating the potential for non-matching emails when checks are made using strict equality
The option you are looking for is called account linking.
You can find more info at https://auth0.com/docs/link-accounts
We are building a CRM type app although this would apply to any application where there are "members" and "staff" e.g. a shopping site, dating site, facebook etc.
In our app, users can change their password the usual way, by resetting it with email confirmation. Users can also have more than one email address associated with their account.
What we are trying to work out is how to prevent staff using the system taking over the accounts. We want staff to be able to edit the email address (because someone may phone in and request a change); the issue then is they can simply change the email to one they control - and request a password re-set as a user.
Are there any recommended best practices for this?
You could require the user to also authenticate the action by other means, such as when the email address is changed the user is sent a confirmation code via text message that they must input somewhere.
Another means would be to only allow access to the account if certain information is inputted correctly. This could be address information or DOB. It is unlikely that this information could be guessed from something like a name or account number.
1) Add one of those silly security questions like "What is your favorite color?" and store the answer, encrypted, in the database. Staff could edit the email to their heart's content, but if they didn't know the answer to the secret question the system wouldn't let them change the password. If you have concerns about staff trustworthiness, then you need to introduce something outside their control that serves as a final gateway before you can change the user account.
I imagine a simple implementation would simply check to see if the user reset their password. If so, on login, it challenges them with the security question to "authenticate" them before allowing them to proceed.
2) Logging, monitoring, and auditing. Record which staff accounts accessed the email address change form, what address(es) they changed, what they changed them too, and when they changed them. Also record the connection information of the people accessing the accounts. If your logs show one IP address accessing 4-5 completely disparate accounts, you might need to look into that. (Yes, I know you can use proxies etc. to mask this. Not perfect but it'd weed out the chaff pretty fast).
3) Hire trustworthy people! #2 should really only need to be used as a "check" against abuse instead of the end all be all to stop it.
I've discovered recently LightOpenID wich i'm going to use as a login system for all my next websites.
As i'm fetching some infos when users register/login with LighOpenID, I'd like to know if it's technically ok to use user's email as unique id in my USERS table or if it's a bad idea ?
Thanks guys ,
FX
Thinks to consider:
It isn't mandatory to have an e-mail account linked to your OpenID account.
If there is an e-mail address, you are not guaranteed to get it back from the server, even if you ask.
Even if you get the address, you'd still need to validate it (e.g., by sending an e-mail message with a random token).
Users will probably own more than one OpenID identifiers (you are in such situation as soon as you open accounts at some major services like Google or Yahoo). Some of them will share the same e-mail address, some will not, and some will not even have an e-mail address set.
When the user changes his e-mail address behind the scenes, he'll lose his account at your site.
Using the e-mail as key does not really offer any advantage I can think of.
My advice is that, if you want to use OpenID, you should do it right. Read the OpenID URL from $openid->identity() after successful validation and use that to identify the user.
Additionally:
Keep in mind that URLs can be long; don't try to stuff it into a VARCHAR(100) column.
You might want to implement linked identities as Stack Overflow does.
It depends on your service. Normally, every email-adress is only assigned to one person. If multiple accounts per user are not wanted, it's ok.
Some families have a family-email-adress. But I guess they would also use the same account.
Why don't you take the OpenID as the unique ID? OpenIDs are unique and you get the OpenID before you get the Email-Adress, if you use only OpenID for logging in.
If I had a poll on my site, and I didn't want to require a registration to vote, but I only wanted each visit one, how might I do this?
Let's say a visitor from IP 123.34.243.57 visits the site and votes. Would it then be safe to disallow anyone from 123.34.243.* from voting? Is this a good strategy?
What's another one?
This is a fundamental challenge with all voting sites on the Internet, and you're just breaking the surface of the problem.
The way you've phrased it, you "only want to allow each visit one [vote]" indicates that you want to allow them to vote once each time they open their browser and go to the site. I don't think this is really what you seek.
I suspect what you want is that a given individual Person can vote only once ever (per survey, maybe).
The problem is, once you've framed the question properly, the problem becomes much more clear. You're not trying to identify an Internet node (IP address), visit (session cookie), browser instance (persistent cookie), or computer (difficult also to identify).
You can use techniques with Cookies, and they were suitably for a typical user. Subverting this technique is as easy as
- Clearing your cookies in the browser,
- Disallowing cookies in the browser,
- Opening another browser,
- Walking to another computer,
- Using an anonimizer,
- ... endless other ways.
You can do validation by e-mail address, but you indicated you don't want to do registration, so I don't believe that solves you problem either.
If you really need to identify a unique user for a voting system, you'll need to have some authority who's willing to vouch for the identity of any given user, or only allow the software to be accessed from a trusted platform.
The first technique requires registration (and often a costly and time-consuming registration at that), that verifies the actual legal name and location of the individual. Then, using Public Key Infrastructure (aka Digital Certificates), you can identify an individual person based on the credentials he supplies.
The second technique, requiring a trusted platform, relies on the hardware following certain pre-determined behavior. You could, for example, create a voting site that works through the XBox 360 or iPhone. You would create an app that is installed to one of those devices. Based on the way the platform is protected, you could use uniqueness characteristics, such as the hardware address or Live ID on the XBox 360 or the hardware address or telephone number on the iPhone, to get general assurance that the user is the same one who has visited before. Because you have control over the application and the user specifically does not, due to the nature of the trusted platform, you have reasonable assurance that most users will not be able to subvert the intent of the application.
I suspect this is a long-winded way of saying you can do it, but it's a far from easy problem to solve.
Consider political elections and how much resources and energy goes into making those fair and anonymous, and still it's a very challenging problem.
Using the public IP for this would probably be a bad idea. Unique visitors from the same corporate LAN would all look like one user if you use this approach.
Perhaps cookies? I believe that is what most sites use.
Combine with some sort of monitoring, automatic or manually (for instance log file analysis). Be suspicious of traffic patterns that indicate a script.
No, you can't use IP address or IP spans to identify unique users. For several reasons:
Stopping a whole span will stop users who haven't voted.
People who get an IP adress dynamically will get a different IP address later.
People in a local network (like a big company) share the same public IP address.
You could use a cookie to flag who has voted. That will be a lot better as it doesn't hit as blindly, but it's of course not completely accurate as people can clear the cookies and browse with more than one browser.
To make a completely accurate identification of the users so that you are really sure that noone votes more than once, you need a login for the users. Well, with the exception for the fact that people could create more than one account of course...
block a ip range is not a good strategy, you can have 2 option to indentify the already voted user, their IP and cookie. after they voted, set a cookie and don't allow them to vote again.
they can clear cookie and change the IP, but it's acceptable for anonymous voting, if you want a better strategy, let's them register for voting
You should block just that particular IP, not the whole IP range!
If you don't have a registration, this is the best solution, but not for users!
You can prevent someone from voting multiple times. but you also may block some other users from voting and that's because of NAT.
Network Address Translation (or NAT) allows multiple users use a single IP to access internet.
But this is OK because NAT is not used heavily and few users will be disallowed from voting.
However, cookies is not the good solution. because the user can easily erase the browser cookies and vote again. Even worse, he/she can write a script to vote automatically many times!
We are in the early design stages of a major rewrite of our product. Right now our customers are mostly businesses. We manage accounts. User names for an account are each on their own namespace but it means that we can't move assets between servers.
We want to move to a single namespace. But that brings the problem of unique user names.
So what's the best idea?
Email address (w/verification) ?
Unique alpha-numeric string ("johnsmith9234")?
Should we look at OpenID?
EMAIL ADDRESS
Rational
Users don't change emails very often
Removes the step of asking for username and email address, which you'll need anyway
Users don't often forget their email address (see number one)
Email will be unique unless the user already registered for the site, in which case forward them to a forgot your password screen
Almost everyone is using email as the primary login for access to a website, this means the rate of adoption shouldn't be affected by the fact that you're asking for an email address
Update
After registration, be sure to ask the user to create some kind of username, don't litter a public site with their email address! Also, another benefit of using an email address as a login: you won't need any other information (like password / password confirm), just send them a temp password through the mail, or forgo passwords altogether and send them a one-use URL to their email address every time they'd like to login (see: mugshot.org)
OpenID is very slick, and something you should seriously consider as it basically removes the requirement to save local usernames and passwords and worry about authentication.
A lot of sites nowadays are using both OpenID and their own, giving users the option.
If you do decide to roll your own, I'd recommend using the email address. Be careful, though, if you are creating something that groups users by an account (say, a company that has several users). In this case, the email address might be used more than once (if they do work for more than one company, for example), and you should allow that.
HTH!
I like OpenID, but I'd still go with the email address, unless your user community is very technically savvy. It's still much easier for most people to understand and remember.
If you use an email address for ID, don't require that it be verified. I learned the hard way about this when one day suddenly the number of signups at my site drastically decreased. It turns out that the entire range of IP addresses including my site's IP was blacklisted. It took a long time to resolve it. In other cases, I have seen Gmail marking very legitimate emails as spam, and that can cause trouble too.
It's good to verify the email address, but don't make it block signups.
Right now our customers are mostly businesses.
People seem to be missing that line. If it's for a business, requiring them to login via OpenID really isn't very practical. They'd either have to use an external OpenID provider, or their poor tech people would have to setup and configure a company OpenID.
If this were "should StackOverflow require OpenID for login" or "Should my blog-comment-system allow you to identify yourself via OpenID", my answer would be "absolutely!", but in this case, I don't think OpenID would be a good fit.
If most of your customers are mostly businesses then I think that using anything other than email creates problems for your customers. Most people are comfortable with email address login and since they are a business customer will likely want to use their work email rather than a personal account. OpenID creates a situation where there is a third party involved and many businesses don't like a third party involved.
I think that OpenID is definitely worth looking at. Besides giving you a framework in which to provide a unified id for customers, it can also provide large businesses with the ability to manage their own logins and provide a common login across all products that they use, including your own. This isn't that large of a benefit now when OpenId is still relatively rare, but as more products begin to use it, I suspect that the ability to use a common company OpenId login for each employee could become a good selling point.
Since you're mostly catering to businesses, I don't think that it's all that unreasonable to offer to host the OpenId accounts yourself. I just think that the extra flexibility will benefit your customers.
If you are looking at OpenID you should check out http://eaut.org/ and http://emailtoid.net. Basically you can accept email addresses for a login and behind the scenes translate them to OpenID without the user having to know anything. Its pretty slick stuff...
I personally would say Email w/ Verification, OpenId is a great idea but I find that finding a provider that your already with is a pain, I only had an openId for here cause just 2 days before beta I decided to start a blog on blogspot. But everyone on the internet has an email address, especially when dealing with businesses, people aren't very opt to using there personal blog or whatnot for a business login.
OpenID seems to be a very good alternative to writing your own user management/authentication piece. I'm seeing more and more sites using OpenID these days, so the barrier to entry for your users should be relatively low.