I've noticed that there are a lot of users that misspell their email addresses when registering. For example, if the email is example#gmail.com, the user may write example#gmail.con. In a registering process, this may lead to the user registering wrong without him/her being aware of.
Is it a good idea to implement a function that changes .con for .com? This would be a problem if .con email addresses exist because they wouldn't be able to register. Do .con email addresses exist?
.con emails cannot exist (right now) because there is not a top-level domain (TLD) named .con
If you go to the Wikipedia page or tld-list.com, you'll see that there isn't a .con
.computer
.condos
.construction
.consulting
.contact
.contractors
.cooking
No .con to be found.
You should probably popup a warning instead of automatically fixing it, though, so that clients are conscious that they made a mistake.
As of today, there is no .con top-level domain (according to https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains#C ).
Is it a good idea? That's more of a Product question than a technical question :) Maybe just prevent the user from entering such an address using client-side validation instead of replacing it for them automatically?
my goal is to give my customers an option to lock their App's Data, so when they give their iPad/iPhone to someone else for an extended period of time, users can't access or accidentally look at confidential data.
[Some Background: It's a medical Application where physicians/staff-members would give iPads to patients. Now the patients are supposed to access some contents, yet shouldn't be able to look at other patients data]
So far, I have a password inside my App. But when a staff-member forgets and wants to reset it, the only thing I can do is "deletion of the whole database". I have a Disclaimer telling people to store their password somewhere, but this is still not the optimal user experience.
Is there anyway I could authenticate the user via his Apple-Password? This way only the person knowing the Devices-Account password can access the data and can always reset the Apple-Password with Apple.
PS: Server-Solutions, like having a User-Password pair with reset-via-mail on a server of mine is out of the question, since it would add to much complexity for the users and in many medical situations the Device shouldn't have access to the web.
Multiple thoughts:
I am not aware of any native public API to authentication using Apple password.
If your app is enterprise app, possibly you can use native private API. I would recommend to disassemble AppStore and check how does it do authentication then
You can also to try to access to some Apple web page which requires authentication and pass to it apple account and password and see what it will return. If it authenticated correctly, then you are fine and you can reset a password.
To make it secure, you will need to ask a user to enter it for a first time, so you can encrypt your encryption keys using authentication material (so you can decrypt encryption key later on).
However, I am not very big fan of this solution, since you can change Apple password and you will be stuck in such case.
Server solution is the best option and it's not that complex. Another option is Forgot password. You ask something what administrator know ("What is your first pet?") and he enters the answer when your application is configured and this answer could be used later to unlock your app.
P.S. And the best solution at the end (which is absolutely shameless self advertisement). A startup which I am part of (SpydrSafe) works on the product which solves exactly your problem. In fact, healthcare is one of the verticals which whom we actively works. If you are interested, contact me (my email is in profile)
if you authenticate the user via apple password, and they forget their apple password, then in order for them to retrieve that password is by reset-via-email .... so either way you are stuck with that dilemma.
As for actually using your apple password, no.
Best way to get what you want is to have the password stored somewhere in real life. Like another computer that the doctors can report to and ask for passwords or just don't forget the password.
If I have a Facebook app, and my users agree to allow my app to access their information, photos, friends, etc, is it ethical to grab their information when they log in, and then saving it in memory so that the next time he goes to my app, it can load faster?
If so, what about when the user logged off? Is the right thing to do to is to delete all the cached information and photos that the user provided?
Has Facebook got any way to detect that we're doing this (saving their information, etc)?
EIDT: Just to be clear, Facebook's term and agreement is not very clear on this matter (agreeing to access information is not always equal to agreeing to have the information stored). As in where I'll be storing the data, it will be just in the user's disk, not my own server. So I can't guarantee that the data is being encrypted securely (If someone steal the phone, that someone will probably be able to get the data)
And yes, my intention is to give my users a better app experience, not anything else.
EDIT2: I'm torn, one answer with very high votes says it's ok because I'm providing a better user experience, but others says I'm breaching privacy. Can anyone provide links to the documentations? Or can more people vote? I'm really glad for the responses!
You're not being malicious. Providing the user a faster experience is beneficial to both the user and to you.
With that said, if the data is not stored on your server in a secure manner and you're being reckless or negligent with the security of that data, then that may raise some ethical questions.
I'd say that it would probably be best to have it off by default, but possibly prompt users to opt-in for faster load times. I think a lot of people would have a problem with you storing their personal data on your server for an arbitrary amount of time past when they sign out of the app.
My answer is similiar to #Keysmack.
I believe you should set default to "off" for caching user's personal fb data.
Opt-in for faster load,performance, more features, etc are all good reasons.
The reason you should offer off by default is that it is actually illegal to store user info without getting their permission in countries such as Australia.
so make sure you consider the legal requirements of the countries your users come from as well as the FB T&C.
Update: Apparently my country passed some new law that makes it a legal requirement to store data for up to 90 days.
If this question has already been asked, please comment so I can remove it.
I'm aware of the advantages of email verification, especially in regard to spamming (which could easily kill me since most of the functionality is in posting comments).
I'm contemplating the removal of email account verification for the application I'm currently building. This is for numerous reasons:
I've noticed other apps/websites
simply don't implement it.
It's far more user friendly then to
skew the user over to their email.
Since the application is moderate in scale and functionality, revisits are short-lived, some users may be inquisitive about it as to sign up, but some might feel it's an overkill to actually go through email verification.
App is not celebrated as to compel visitors to take effort, sign up and verify.
I know I'm getting into the gust of it, and while I'm writing this visitors could've verified their account for the gazillionth time; however, would you agree that for some moderately scaled applications an account verification might deter a casual visitor?
What measures do you personally prefer to undertake?
Why not use some form of federated ID like OpenID and such?
Verification is good if you plan to send email to them on a regular basis. Otherwise if it's just a casual site, you will probably need to offer something compelling to get them to register and provide you a valid email address.
Do you have something compelling?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
The community reviewed whether to reopen this question 3 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm creating a web app that requires registration/authentication, and I'm considering using an email address as the sole user id. Here are what I see as the pros and cons (updated with responses):
PROS
One less field to fill out during registration (it would just be email address, password, and verify password). I'm a big fan of minimalistic registration.
An email address is easier to remember. (thanks Mitch, Jeremy)
You don't have to worry about your favorite username being taken already - you're the only one who uses your email address. (thanks TStamper)
CONS
User has more to type every time they log in.
What if a user wants multiple accounts? They'll need another email address. (Do I even want a user to be able to create multiple accounts?)
Easy for a potential attacker to guess (if they know the target's email address, they know the login id). (thanks Vasil)
Users may be tempted to use the same password they use for their email account, which is bad security. (thanks Thomas)
If you change email addresses frequently, it may be difficult to remember which address you used to sign up for a site after a long hiatus. (thanks Software Monkey)
A hacker could spam the registration form and use "email already taken" responses to generate a list of valid emails. (thanks David)
Not everyone has an email address. (thanks Nicholas)
If I went with email as id, I would provide a mechanism to allow it to be changed in the event a user changes address. In this case users would not be posting content to a public site, so a separate username won't be necessary to protect the email addresses (but it is something to consider for other sites).
Another option is to implement OpenID (which is a whole other debate).
This seems to work for Google, but their services are tightly integrated. What have I missed in my analysis? Do you have any recommendations? Does anyone have experiences to share?
FINAL EDIT
Thank you all for your responses. I have decided to use email as an id, but then allow the creation of a username for login purposes after registration. This allows a little flexibility while keeping registration as short as possible. It also prevents problems when a user changes email addresses (they can just log in with their username and update it). I will also be implementing methods to prevent brute-forcing of email addresses out of the registration and login systems (mainly a cool-down period after repeated attempts).
Personally, I prefer just using my email address as a username. It's one less thing to remember, and I never have to worry about my preferred name being already taken.
Just my 2 cents!
I think you missed a PRO:
Users are likely to remember their email address; and as email addresses are unique, they never have to worry about their preferred username being taken already.
As a user of websites, I can tell you that I hate memorizing unnecessary usernames. I don't use a unique handle or anything so I can never remember which variation of my name I used that wasn't already taken. I'd much rather type my email address.
Also, I like OpenID.
CONS
When the same password is used for the e-mail account, compromising the one automatically means compromising the other.
CON: Not everyone has an e-mail address. Consider if your database is ever accessed by an internal application. If you are running a store, people will call up and place an order by phone and refuse to provide an e-mail address. So while having an e-mail address as the default user ID is cool, be sure to allow alternates to get into the system. (Of course, this depends on the context.)
Learned this one the hard way.
I tend to not prefer pro/con lists, and instead try to think of benefits and challenges.
Challenge:
Some users will be tempted to use their email address from their ISP. Linking to an email alone, may be difficult for the users who forget to update their email in all the web sites they have signed up for before they change ISPs.
Instead:
You should consider allowing a user to provide multiple addresses, as well user-selected id and then let the user decide what they want they wish to do. Perhaps also consider allowing the user to provide an OpenID account.
CON: If I change my email address, suddenly all my account names are invalid. My name doesn't change, but my email often does. I have occasionally revisited a site after a number of years, and been stuck... what was my email address two years ago???
One setup you may want to consider: Have both a username and an email. The email is used to login and is always kept private, the username is used to identify the user in any public interaction, such as posting a comment. It winds up being slightly more secure as both halves of the user login credentials are kept private, whereas if you use a username for both login and public identification, half of the login is already known.
I definitely agree with you about having minimal registration for most cases, but depending on what you're doing you may want to balance that against added security for your users. Four fields isn't outrageous for registration, (username, email, password, confirm password), and if you're feeling particularly adventurous, you could cut it down to three by dropping the confirm password field, or two by emailing them a password that they can change later.
PRO
People hate having to create a unique name that fits their id and that has not already been taken to register for a site..So this is why the user id as EMAIL ADDRESS is so embraced.
ex:TStamper1930, who actually wants to remember 1930 at the end of my name that I really wanted
CON: If a hacker can try registering random email addresses en masse, he or she will be able to figure out which of those addresses are valid based on which registrations fail. This is a tactic that can be used to put together lists of known valid email addresses, which are a hot commodity on the spam black market.
Although now that I think about it, that's a problem that affects any website which asks for an email address as part of the registration process, regardless of whether or not there's a separate username. But it's still something to think about.
Stick to email addresses they are used everywhere, actually most of the major websites use them, they are unique so they save the user from struggling to find a name that's not used by others, also users won't forget their email addresses (in most cases at least :)), which is unlike usernames that they will keep on forgetting if they don't visit your site very often.
You shouldn't be worried about them being too long as all the major browsers (IE, FF .. etc) offer autocomplete to forms which is enabled by default, so you type the first letters in your email and you get a drop down list (ie. autocomplete list) where you just click to enter the whole email, personally I almost never type the email address in full, I always type the first letters then select the email from the autocomplete drop down list. Besides, if you allow users to be remembered (using a Remember Me checkbox and persistent cookies), it will be another reason to not worry about it.
I don't know about your app but usually users having multiple accounts is not desirable in most apps.
One con might be that if it's an email address the login can be guessed by people and brute force attacks attempted. Which is not really a big issue, since on most sites today the logins are publicly displayed.
The biggest pro is that logins are easier to remember this way.
A good setup is to require username and email. Allowing the user to login with either email address or username is very user friendly. An added benefit is the user can change their email address. It would also allow multiple accounts for one email.
To solve your con item of the email being too long to type in every time. I have implemented the StringScan Ruby library.
require 'strscan'
def signup!(user, &block)
self.email = user[:email] unless user[:email].blank?
str = StringScanner.new(self.email)
str.scan_until(/#/)
str.pre_match
self.login = str.pre_match
etc..
Then just change login method to allow either email or login to match password.
This works just like google or mobileme. A user can choose to just type in their email username (ie. username instead of username#gmail.com.)
I'm fighting with removing this right now. Here's a newer CON from the current era.
An email address is considered Personal Identifiable Information (PII) by many governments. Hence extra care needs to be taken any time you display it on a page, or even return it from an end-point.
Consider that many sites allow interactions between different users. This often means the site will provide a list of users to choose from (e.g. a drop-down list, or search results). This ca actually enable the leaking of PII by the site.
Usernames, on the other hand, can be completely anonymous. Given the prevalence today of password managers, users really don't need to actually remember their username and password.
If you don't care about forcing your users to login to your application with Facebook or some other social network (most people don't seem to care), then you can just use their social network email as their 'user id' when referencing other tables/documents (MySQL, Mongo, etc).
I've noticed the bonus to using social media logins is that all the security has been taken care of by said social network, including not allowing 2 users to have the same email or username in their database thus saving you the hassle of having to code for all of that. This is just my personal preference.