여기에는 중요한 원칙이 있습니다. 사용자 비밀번호를 아는 업체는 한 명뿐입니다. 그것은 사용자입니다. 그들의 아내 / 남편, 의사 또는 신부가 아닙니다.

여기에는 사용중인 서비스를 담당하는 프로그래머, 데이터베이스 관리자 또는 시스템 기술자가 포함되지 않습니다. 프로그래머가 사용자가 실제로 암호를 알고 있다는 사실을 증명해야 할 책임이 있기 때문에 문제가 발생합니다. 이는 순수한 방법으로 해결하기가 쉽지 않은 문제입니다.

순수한 해결책은 사용자에게 예측할 수없는 새로운 데이터로 문제를 제기 한 다음이 데이터와 암호를 기반으로 응답을 반환하는 메커니즘을 보유하는 것입니다. 이를 구현하는 한 가지 방법은 사용자에게 새로 생성 된 일부 데이터에 디지털 서명을 디지털 서명하도록 요청하는 것이며, 원래 계정을 만들 때 사용한 것과 동일한 암호화 키 쌍을 사용했음을 수학적으로 증명할 수 있습니다.

실제로 순수한 솔루션에는 실질적인 클라이언트 측 인프라 및 처리가 필요하며 많은 웹 사이트의 경우 데이터 보호에 적합하지 않은 경우가 많습니다.

더 일반적인 해결책은 다음과 같습니다.

애플리케이션에서 비밀번호가 처음 수신되는 시점에서 비밀번호는 애플리케이션의 임의의 ‘소금’값과 함께 해시 함수로 전달됩니다.

그런 다음 원래 문자열을 메모리에 덮어 쓰고이 시점부터 솔트 해시는 데이터베이스에 저장되거나 데이터베이스 레코드와 비교됩니다.

여기서 보안을 제공하는 주요 측면은 다음과 같습니다.

1. 해시에 대한 지식은 인증을 직접 제공하지 않습니다.
2. 해시에서 비밀번호를 역으로 계산하는 것은 실용적이지 않습니다.
3. 레인보우 테이블 (긴 암호 목록 및 계산 된 해시)을 사용하는 것은 결과 해시가 사용자 이름과 암호 모두에 의존하기 때문에 더욱 어려워집니다.

답변