2012-08-06 2 views
0

일반적인 웹 사이트 환경에서 암호 로그인 시스템을 구현하는 방법에 대한 좋은 설명을 찾고 있습니다. 나는 위대한 위키 피 디아 기사와 SO Q & A와 블로그 등을 읽었지 만, 항상 해시를 생성하는 해시를 만드는 것보다는 해시를 생성하는 부분에 초점을 맞추고있는 것 같습니다. 코드 등이 있습니다. 이미 좋은 답변이있는 경우 다시 게시 해 주셔서 사과 드리며 연결하십시오.웹 응용 프로그램에서 암호 해시 및 해시 구현을위한 기본 프로세스

나의 현재 이해는 다음과 같습니다

1) 새로운 사용자가 웹 사이트에 새로운 계정을 생성합니다. 그들은 "암호"를 입력하고 클라이언트 쪽 코드는 긴 임의의 문자열 "소금"을 생성하여 끝에 추가하고 예를 들어 해시 -> BCrypt (암호 + 소금)를 생성합니다. 그런 다음 클라이언트 코드는 해시 된 전체 해시와 해시되지 않은 소금을 서버에 전송합니다.

2) 서버는 전체 해시 및 해시되지 않은 소금을 DB의 사용자 항목에 저장합니다. 사용자 로그인시

3)

들이 다시 소금으로 해시되는 암호,

질문 1을 입력) 클라이언트 측 코드는 각 사용자에 대해 동일한 '무작위'소금 값을 생성 않습니다 어떻게?

질문 2)이 시점에서 클라이언트 측 코드가 단지 소금없이 전체 해시를 전송합니까?

질문 3) 서버 측은 일단 전체 해시를 수신하면 무엇을합니까? (단순히 전송 된 전체 해시를 저장된 전체 해시와 비교해보십시오. 그렇다면 공격자가 데이터베이스에 침입하여 저장된 전체 해시 값을 가져 와서 서버에 직접 로그인하여 로그인 할 수 없습니까?) 로그 인 프로세스는 기본적으로 클라이언트에서 보낸 전체 해시와 데이터베이스에 저장된 전체 해시를 비교하는 서버와 관련됩니다. 질문 4) 암호는 항상 보안 연결을 통해 보내야합니까? 아니면 누구나 볼 수있는 소금물과 해싱으로 만들었습니까?

답변

3

해싱의 목적을 혼란스럽게합니다. 유선 전송을위한 암호를 보호하기위한 것이 아닙니다. 클라이언트는 해시를 생성하지 않습니다. 해시의 목적은 데이터베이스를 손상시키는 침입자가 미리 생성 된 해시 조회 테이블을 사용하여 사용자의 암호가 무엇인지 판단 할 수 없게하는 것입니다.

@jhoyla가 아래의 의견에서 지적한 바와 같이, 산업 등급 생산 계획은 훨씬 더 복잡합니다. 이 때문에,

  1. 는 클라이언트가 서버와의 보안 (암호화, 예를 들어, SSL) 연결을 설정하고 확인을 보통 일반 텍스트에 사용자 이름과 암호를 (전송 :

    계정을 만들려면 암호화 됨).

  2. 서버는 임의의 소금을 생성하고 암호에 추가하고 결과를 해시하며 해시 및 해시되지 않은 소금 값을 저장합니다.

로그인하려면

  1. 클라이언트는 보안 (암호화, 예를 설정SSL) 연결을 사용하고 사용자 이름과 암호를 보통 일반 텍스트로 보냅니다 (암호화 되었기 때문에 OK 임).

  2. 서버는 저장소에서 소금을 검색하고 암호에 추가하고 해시하며 결과를 저장소의 해시 된 암호와 비교합니다. 일치하는 경우 사용자가 로그인했습니다.

왜 이렇게했는지 확인하려면 웹 사이트의 데이터베이스 서버를 성공적으로 공격하여 데이터베이스를 다운로드했다고 상상해보십시오. 이제 사용자 이름, 이메일 주소 및 암호 해시 목록이 있습니다. 암호가 소금에 절인되지 않으면 많은 사람들이 동일한 약한 암호를 사용하기 때문에 많은 해시가 동일 할 가능성이 매우 높습니다. 나는 (예를 들어) 이메일 계정에 같은 약한 암호를 사용하는 사용자 중 한 명의 가능성이 상당히 높다는 것을 알고 있습니다. 그래서 나는이 사전 중 하나와 일치하는 해시를 찾기 위해 다른 사전 암호와 더불어 사전 전체를 해시하고 해시하겠습니다. 히트를 치면 방금 여러 암호가 깨졌습니다. 내가 똑똑하다면, 나는이 목록을 미리 만들어서 빨리 할 수있을거야.

이제 비밀번호가 소금에 절인 경우를 상상해보십시오. 이제는 두 사람이 같은 암호를 사용하더라도 각 암호마다 서로 다른 소금이 생성되어 결과물이 달라집니다. 어떤 암호가 약하고 일반적인 암호인지, 어떤 암호가 강력한 암호인지는 알 수 없습니다. 나는 각각의 가능한 암호에 소금을 붙임으로써 사전 공격을 시도 할 수는 있지만, 암호 해독의 어려움 (시간의 관점에서)은 기하 급수적으로 증가했다.

+2

암호화되지 않은 안전하게 안전하게 전송할 수있는 많은 횟수로 반복적으로 암호를 해시하는 복잡한 방법이 있습니다. 예를 들어 스키마는 일 수 있습니다. 1. 클라이언트가 계정을 만들고 암호를 해시합니다. 10,000 번. 2. 서버는 해시와 10,000이라는 숫자를 저장합니다. 3. 로그인 할 때 클라이언트는 10,000 - n 회 암호 해시를 제출합니다. 4. 서버는 해시를 한 번 더 해시하고 저장된 해시와 비교 한 다음 동일한 경우 저장된 해시를 제출 된 해시로 바꾸고 숫자를 줄입니다. 누군가가 해시를 다시 제출하는 것을 방지합니다. – jhoyla

+0

소금은 각기 다른 소금을 사용하더라도 각 계정에 대해 사전 공격을하는 것이 매우 빠르기 때문에 사전 공격을 너무 많이 막지는 못합니다. 그러나 무차별 공격이 필요한 좋은 암호를 사용하면 공격자가 동시에 모든 계정을 포기하지 않고 강제로 한 번에 하나의 계정 만 강제로 공격 할 수 있습니다. –

+0

감사합니다. 아주 명확한 대답입니다. – 0xor1

2

직접 구현하지 마십시오! 당신이 그것을 배우기 위해 필요하다면 @ 크리스가 당신에게 대답했습니다. 하지만 작동하는 소프트웨어가 필요한 경우에는하지 마십시오. 모든 언어에는 보안 라이브러리가 있으며 모든 데이터 저장소 (LDAP, 데이터베이스)에는 이미 구현 된 암호 저장 메커니즘이 있습니다. 그것을 사용하고, 바퀴를 다시 발명하지 마십시오. 어떤 세부 사항을 놓치기 때문에

+0

나는 이것을 알고 있으며 나는 당신에게 동의한다. 나는 단지 클라이언트가 무엇을하는지, 클라이언트가 서버에 보내는 것 그리고 서버가 무엇을하는지에 대해 이해하고 싶다. 당신이 말했듯이 나는 결코 이것을 구현하지 않을 것이다. – 0xor1