[Stock-Insider] 회원가입_1

회원가입의 참조는 역시 갓글로 하기로 했다. (단순해서 좋다)
근데 사실 성과 이름도 필요없지 않은가??
구글은 왜 성이랑 이름이 필수인지 모르겠다. (선택사항이 맞지않나?)
(뒤에 생년월일 물어보는건 성인 Content 때문이니까 이해가 된다만)

그래서 나는 Email과 Password 만으로 가입할 수 있는 회원가입 기능을 만들려 한다.
Email은 도메인마다 다르므로 간략히 ID@DOMAIN 형태로 받으려하고
Password를 어떤 형태로 받을까를 고민하다
어떤 기획자분의 좋은 블로그 글을 발견했다!

기존 한국인터넷진흥원 KISA 기준 비밀번호 Guide

• 최소 10자리 이상 : 영어 대문자, 소문자, 숫자, 특수문자 중 2종류 문자 조합으로 구성
• 최소 8자리 이상 : 영어 대문자, 소문자, 숫자, 특수문자 중 3종류 문자 조합으로 구성

이 기준은 미 국립표준기술연구소(NIST, National Institute of Standards and Technology)에 근무하던 빌 버(Bill Burr)가 2003년에 해커로부터의 비밀번호 해킹을 어렵게 하기 위해 만든 규칙으로 동 기관에서 발간한 '전자인증 가이드라인(Electronic Authentication Guideline) 문서에 담겨있던 규칙을 KISA에서도 인용한 것이다.

그런데 2017년 NIST에서 새로 발간한 디지털 아이덴티티 가이드라인(Digital Identity Guidelines)에서 복잡한 조건들로 인해 사용자들이 비밀번호를 제대로 관리하지 않아 오히려 보안성이 떨어져 이용자 보호 측면에서 실익이 없다고 인정하고 비밀번호를 여러 문자로 조합하고 일정 기간마다 바꾸도록 한 내용을 삭제하였으며 최근 빌 버 또한 이 규칙을 만든 것에 대해 후회한다고 밝혔다.

따라서 KISA도 이 새로운 디지털 아이덴티티 가이드라인 정책을 준용하여 아래와 같이 비밀번호 가이드라인을 수정하였는데 대다수 기획자들이 이 정책의 변화를 인지하거나 반영하지 못하고 있는 것 같다. (그리고 가이드라인은 가이드라인일 뿐이다.)

출처: https://germweapon.tistory.com/384 [이렇게 기획하면 안 돼요! #회원가입 글 중에서]
(인용을 허락해주셔서 감사합니다!)

변경된 한국인터넷진흥원 KISA 기준 비밀번호 Guide

• 최소 10자리 이상 : 문자 조합 필요 없음
• 최소 8자리 이상 : 문자, 숫자, 기호 중 2종류 조합 구성

보안상의 문제가 없다면 사용자 편의성을 위해 심플한 형식이 Best라고 생각한다.
고로 password 형식은 위의 기준을 따르고자 한다.

다음으로 회원 Table 구성에 대해 고민하다 오픈소스 프로그램의 Column을 참조하려한다.
(http://www.ciboard.co.kr/manual/tables/member)

Column Naming도 고민이 되어서 찾아보았는데 뭔가 확고한 Convention은 없는 듯 했다.
좀 Old한 스타일로 치부되는 규칙들(TB 등)은 배제하고 알아보던 중 이 글들이 제일 좋았다.
(https://taptorestart.tistory.com/entry/MySQL-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4%EB%AA%85-%ED%85%8C%EC%9D%B4%EB%B8%94%EB%AA%85-%EC%BB%AC%EB%9F%BC%EB%AA%85%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%A7%80%EC%96%B4%EC%95%BC-%ED%95%A0%EA%B9%8C)
(URL부터 신뢰가 가는 https://www.sqlstyle.guide)
처음에 Table명을 user라고 하려했는데 예약어는 피하라하여 member로 변경했다.

CREATE TABLE `member` (
  `member_id` bigint NOT NULL AUTO_INCREMENT COMMENT 'pk(autoInc)',
  `member_email` varchar(100) NOT NULL COMMENT 'Personal ID',
  `member_password` varchar(100) NOT NULL COMMENT 'sha256',
  `member_email_cert` boolean NOT NULL DEFAULT false,
  `member_email_recieve` boolean NOT NULL DEFAULT false,
  `member_is_admin` boolean NOT NULL DEFAULT false,
  `member_register_datetime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `member_lastlogin_datetime` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`member_id`)
) 

결과물로 만든 Table이다.
PK는 id로 하라는 글도 있고 table명_id로 하라는 글도 있었는데
좀 더 구체적으로 써주는게 좋지 않을까해서 member_id로 결정했다.
가입자 ip도 추가하면 재밌을 것 같았지만 뭔가 해킹하는 느낌이라 제외했다.(못하자나...)

다음으로 기능이다.
(기능을 먼저 정의하면 TestCode나 Interface를 더 명확하게 만들 수 있다고 들었다.)

1. 유효성 검사(Validation)
   1) 이메일, 비밀번호 형식 => Frontend에서 정규식을 활용하여 Check
   2) 이메일 중복 => Backend에서 DB 데이터와 비교(비동기)하여 Check
2. Password를 DB에 저장시 SHA(Secure Hash Algorithm)를 활용하여 저장
3. 회원가입 완료시 인증 Email로 계정 활성화

먼저 유효성 검사의 경우 고민이 들었던게 미리 검사를 다 해버리면
TestCode를 짤 필요가 없는건가라는 생각이 들었다.
그리고 매번 다른 값이 들어올텐데 그걸 어떻게 미리알고 예상값을 정하는지도 모르겠다.
(이에 대한 TestCode 작성 방법은 더 찾아봐야겠다.)

SHA의 경우 개발자가 유저의 원본 Password을 알 수 있게되면 해킹의 우려가 생기기 때문에 원본 Password를 암호화하여 DB에 저장하였다가 필요하면(중복검사 등)
다시 복호화하여 사용한다고 한다.(중복검사는 그냥 암호화 된 것끼리 비교하면 안되려나?)

마지막 인증 메일은 좀 고민되었는데 내 사이트에 굳이 인증 메일까지 하면서까지
제한 할만한 기능이 없는데 필요할까라는 고민이었다.
하지만 일단 만들고 나중에 그럴만한 기능을 추가하자는 결정을 내렸다.
일단은 인증시 Login 상태 아이콘이라도 멋진 걸로 바꿔드릴 생각이다. (아 참 좋구나...)

회원가입 관련 기획은 끝났고 이제 실제 Code로 구현을 시작해보자!