이메일 주소를 사용자 ID로 사용할 때의 장단점은 무엇입니까?
등록 / 인증이 필요한 웹 앱을 만들고 있으며 이메일 주소를 단독 사용자 ID로 사용하는 것을 고려하고 있습니다. 다음은 장단점으로 보는 것입니다 (응답으로 업데이트 됨).
장점
등록 할 때 입력해야 할 필드가 하나 적습니다 (이메일 주소, 비밀번호 및 비밀번호 확인). 저는 최소한의 등록을 좋아합니다.
좋아하는 사용자 이름이 이미 사용되는 것에 대해 걱정할 필요가 없습니다. 귀하는 귀하의 이메일 주소를 사용하는 유일한 사람입니다. ( TStamper에게 감사 드립니다 )
단점
사용자는 로그인 할 때마다 더 많이 입력해야합니다.
사용자가 여러 계정을 원하면 어떻게합니까? 다른 이메일 주소가 필요합니다. (사용자가 여러 계정을 만들 수 있기를 원합니까?)
잠재적 인 공격자가 추측하기 쉽습니다 (대상의 이메일 주소를 알고 있으면 로그인 ID를 알고 있음). ( Vasil에게 감사드립니다 )
사용자는 이메일 계정에 사용하는 것과 동일한 암호를 사용하려는 유혹을받을 수 있으므로 보안이 취약합니다. ( Thomas에게 감사합니다 )
이메일 주소를 자주 변경하는 경우 오랜 중단 후 사이트에 가입 할 때 사용한 주소를 기억하기 어려울 수 있습니다. ( Software Monkey에게 감사드립니다 )
해커는 등록 양식을 스팸하고 "이미받은 이메일"응답을 사용하여 유효한 이메일 목록을 생성 할 수 있습니다. ( David에게 감사합니다 )
모든 사람이 이메일 주소를 가지고있는 것은 아닙니다. (감사합니다 Nicholas )
이메일을 id로 사용하면 사용자가 주소를 변경하는 경우 변경 될 수있는 메커니즘을 제공합니다. 이 경우 사용자는 공개 사이트에 콘텐츠를 게시하지 않으므로 이메일 주소를 보호하기 위해 별도의 사용자 이름이 필요하지 않습니다 (하지만 다른 사이트에서는 고려해야 할 사항 임).
또 다른 옵션은 OpenID를 구현하는 것입니다 (이것은 완전히 다른 논쟁입니다).
이것은 Google에서 작동하는 것처럼 보이지만 서비스는 긴밀하게 통합되어 있습니다. 분석에서 무엇을 놓쳤습니까? 권장 사항이 있습니까? 공유 할 경험이있는 사람이 있습니까?
최종 편집
응답 해 주셔서 감사합니다. 나는 이메일을 아이디로 사용하기로 결정했지만 등록 후 로그인 목적으로 사용자 이름 생성을 허용합니다. 이것은 등록을 가능한 한 짧게 유지하면서 약간의 유연성을 허용합니다. 또한 사용자가 이메일 주소를 변경할 때 문제를 방지합니다 (사용자 이름으로 로그인하여 업데이트 할 수 있음). 또한 등록 및 로그인 시스템에서 이메일 주소의 무차별 대입을 방지하는 방법을 구현할 것입니다 (주로 반복적 인 시도 후 휴지 기간).
나는 찬반 양론 목록을 선호하지 않고 대신 이점과 과제를 생각하려고 노력합니다.
도전:
일부 사용자는 ISP의 이메일 주소를 사용하고 싶어합니다. ISP를 변경하기 전에 가입 한 모든 웹 사이트에서 이메일을 업데이트하는 것을 잊은 사용자는 이메일에만 연결하는 것이 어려울 수 있습니다.
대신 :
사용자가 여러 주소와 사용자가 선택한 ID를 제공 할 수 있도록 허용 한 다음 사용자가 원하는 작업을 결정하도록해야합니다. 사용자가 OpenID 계정을 제공하도록 허용 할 수도 있습니다.
개인적으로 저는 이메일 주소를 사용자 이름으로 사용하는 것을 선호합니다. 기억해야 할 것이 하나 적고 내가 선호하는 이름이 이미 사용되는 것에 대해 걱정할 필요가 없습니다.
내 2 센트!
PRO를 놓친 것 같습니다.
사용자는 자신의 이메일 주소를 기억할 가능성이 높습니다. 이메일 주소는 고유하므로 선호하는 사용자 이름이 이미 사용되는 것에 대해 걱정할 필요가 없습니다.
단점
- 이메일 계정에 동일한 암호를 사용하는 경우 하나를 손상시키는 것은 자동으로 다른 하나를 손상시키는 것을 의미합니다.
웹 사이트 사용자로서 불필요한 사용자 이름을 외우는 것이 싫다고 말할 수 있습니다. 나는 독특한 핸들이나 다른 것을 사용하지 않기 때문에 내가 사용한 내 이름의 어떤 변형이 아직 사용되지 않았는지 기억할 수 없습니다. 내 이메일 주소를 입력하고 싶습니다.
또한 저는 OpenID를 좋아합니다.
단점 : 모든 사람이 이메일 주소를 가지고있는 것은 아닙니다. 내부 응용 프로그램에서 데이터베이스에 액세스 한 적이 있는지 고려하십시오. 상점을 운영하는 경우 사람들 이 전화로 전화를 걸어 주문하고 이메일 주소 제공을 거부합니다. 따라서 이메일 주소를 기본 사용자 ID로 사용하는 것은 좋지만 대체 사용자가 시스템에 들어갈 수 있도록 허용해야합니다. (물론 상황에 따라 다릅니다.)
이것을 어려운 방법으로 배웠습니다.
고려할 수있는 한 가지 설정 : 사용자 이름과 이메일을 모두 가지고 있습니다. 이메일은 로그인에 사용되며 항상 비공개로 유지되며 사용자 이름은 댓글 게시와 같은 공개 상호 작용에서 사용자를 식별하는 데 사용됩니다. 사용자 로그인 자격 증명의 절반이 모두 비공개로 유지되기 때문에 약간 더 안전하지만 로그인 및 공개 ID 모두에 사용자 이름을 사용하면 로그인의 절반이 이미 알려져 있습니다.
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.
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???
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.)
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.
'Nice programing' 카테고리의 다른 글
.NET 4.0 작업 패턴을 사용하여 HTTPClient .ReadAsAsync로 JSON을 배열 또는 목록으로 역 직렬화 (0) | 2020.11.11 |
---|---|
Groovy 클로저에서 "계속"시뮬레이션을위한 최상의 패턴 (0) | 2020.11.11 |
추상 클래스 vs. 인터페이스 vs. 믹스 인 (0) | 2020.11.11 |
순환 참조를 사용하여 JavaScript 객체 문자열 화 (JSON으로 변환) (0) | 2020.11.11 |
셸에서 셀러리 주기적 작업을 수동으로 실행하려면 어떻게해야합니까? (0) | 2020.11.11 |