로그인 에 대하여.

우리가 작성하는 password 는 ***로 표현되기 마련이다.

사용자들이 시각적으로 접할때에는 안전하다는 느낌을 받을수 있다.

하지만, form 태그로 작성하고 ajax 로 통신하는 와중에

 

SSL프로토콜 위에 있는 암호호된 HTTPS를 사용하지 않거나, 비밀번호에 대해 암호화를 진행하지 않는다면,

우리는 스니핑 과 같은 보안 위협을 받게된다.

 

> 스니핑 : 네트워크상의 데이터를 도청하는 행위

 

> HTTPS와 SSL를 같은 의미로 이해하고 있는 경우가 많다. 이것은 맞기도 틀리기도 하다. 
  그것은 마치 인터넷과 웹을 같은 의미로 이해하는 것과 같다. 
  결론적으로 말하면 웹이 인터넷 위에서 돌아가는 서비스 중의 하나인 것처럼
  HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜이다.

 

따라서 회원가입의 경우 ClientSide에서 보낸 정보를 Server에서  사전에 지정된 암호화 방식으로 암호화한후 DB에 저장한다.

 

로그인의 경우도 마찬가지이다. 

 - Client에서 보낸 비밀번호 평문을 Server에서 사전에 지정된 암호화 방식으로 암호화한후, DB에 있는 정보와 비교해서 처리해준다.   (해당 과정에서의 DB조회를 줄이기 위해 AccessToken을 부여해준다.)

Client 는 애초에 오염될수 있는 존재로 보기 때문에, client 측에서 암호화관련된 활동은 하지 않는다.

====================================================

Password는  기밀성을 유지하기 위해 복호화가 된다는 성질 자체가 허용되지 않는다.

따라서  양방향 암호화 , RSA암호화 등을 두고 Hash Function 사용하는 이유이다.

HashFunction 은 애초에 복원성질이 없다.

따라서 Google이나 Facebook등의 로그인의 경우, 비밀번호를 잃어버릴경우 본사도 비밀번호를 알려주지 못한다.단지 Reset을 할수 있을뿐이다.

 

 

 

====================================================

Hash Function의 취약점은 어떻게하나요? 

  - 반복되는 암호화로 취약점이 생길수 있다.   

      -> 원본 문자열에 임의의 Salting을 붙여 hash 를 해서 해결한다.

      -> Hash된 다이제스트를 또 Hash 한다.  (key streching)

      ---> 이둘을 해결해준 hash함수가 bcrypt 라이브러리에 있다.

 인식 가능성(recognizability)

동일한 메시지가 언제나 동일한 다이제스트를 갖는다면, 공격자가 전처리(pre-computing)된 다이제스트를 가능한 한 많이 확보한 다음 이를 탈취한 다이제스트와 비교해 원본 메시지를 찾아내거나 동일한 효과의 메시지를 찾을 수 있다. 이와 같은 다이제스트 목록을 레인보우 테이블(rainbow table)이라 하고, 이와 같은 공격 방식을 레인보우 공격(rainbow attack)이라 한다. 게다가 다른 사용자의 패스워드가 같으면 다이제스트도 같으므로 한꺼번에 모두 정보가 탈취될 수 있다.

 

다이제스트란?  해시함수를 거쳐 나온 값을 말한다.

=======================================================================

Hash Function들을 조합하고 여러번한다고 안전한것이 아니다. 

매번  매 회원가입,비밀번호변경마다 랜덤하게 작동하는 salting기법을 사용해서 hash값을 만들어내라. 그것이 정답이다.

긴salting+매순간 새로운 salt 그리고 사용자마다 salt값을 DB테이블에 저장해준다면 안전한것이다.

starplatina.tistory.com/entry/%EB%B9%84%EB%B0%80%EB%B2%88%ED%98%B8-%ED%95%B4%EC%8B%9C%EC%97%90-%EC%86%8C%EA%B8%88%EC%B9%98%EA%B8%B0-%EB%B0%94%EB%A5%B4%EA%B2%8C-%EC%93%B0%EA%B8%B0