나는이 주제가 백만 번 논의되었습니다. 그러나 그것은 나에게 새로운 것이고, 실제로 그것에 대해 읽거나 읽을 수있게되면 실제로 일어나는 일이나 일어날 일을 이해할 수 있습니다.암호, 소금, 해시, DB : 백만 시간 동안
사용자의 암호가 해시 된 저장소에 사용자 별 소금을 추가하므로 저장된 암호 해시가 hash (password + perusersalt)와 같습니다. 이렇게하면 다른 사용자의 동일한 비밀번호가 DB에 다른 문자열로 저장됩니다. 시원한. 하지만 누군가 DB에 침입하여 해시 된 암호를 찾는 것에 대해 걱정하지 않습니다. 나는 사용자 이름과 암호 조합에 대해 내 서버에 질의를하는 사람에 대해 걱정하고 있습니다. 이 경우 사용자 이름과 암호의 올바른 조합으로 로그인에 성공할 수 있기 때문에 소금에 절인 해시 된 암호 저장은 쓸모가 없습니다. 권리?
이 시나리오에서 소금이 거의 쓸모가 없다는 인상하에 나는 맞습니까? 서버는 인터페이스에서 사용자 이름과 암호 만 허용하기 때문에 (염분이 전송되지 않음) 정상적인 사전 공격이 가능합니다. 맞습니까?
그래서 소금은 DB에 액세스 할 수있는 사용자로부터 비밀 번호를 난독 화 (반대 레인보우 테이블 조회 만 가능) 할 수 있습니다. 흠.
관련 정보 : 내 웹 앱은 일반 암호를 전송하지 않습니다. 암호는 이미 해쉬 된 클라이언트 측으로, 누군가가 도난당한 암호에 대한 책임을 완전히 배제하기 위해 사용되며, 모든 것이 SSL을 사용합니다.
사용자 이름과 비밀번호의 올바른 조합이 물론 로그인에 성공해야하기 때문에 보안 수준을 최대한 높이는 것이 중요합니까?
내 머리에 엉망진창을 정리해 주셔서 감사합니다.
웹 프론트 엔드를 제어하는 경우 인위적으로 분당 시도 할 수있는 암호의 양을 제한하고 일부 잘못된 시도 후에 속도 저하를 시도한 후 hotmail과 같은 다른 사이트에서 사용하는 보안 문자 이미지를 추가 할 수 있습니다. – David
RDBMS 솔루션에 따라 방정식의 웹 측면을 제어하지 않아도 일반적으로이를 제어 할 수 있지만 새 DB로 전환하기로 결정하면 이식성이 떨어질 가능성이 있습니다. –
또한 bcrypt를 사용할 수도 있습니다. bcrypt는 느린 속도로 서버 속도에 관계없이 느린 속도로 진행되도록 설계되었습니다. –