는 복어으로는 같은 반환 ALG 해시의 종류에 대한 정보를 포함db에 PHP crypt() 결과를 저장하는 것이 안전합니까? 예를 들어
$2a$12$DEzG.CRsHpxpTOAHooQ.wuR6Xe9h6PxFPhOcOvf.lqDNw1TVYVnEO
을 그리고 소금이 포함되어 있습니다. 많은 리소스가 db에이 값을 저장한다고 말하면 안전 할 것입니다. 그러나 일부 사람들은이 값들에 대해 공통된 암호 목록을 테스트하여 그 중 일부를 해독 할 수 없었습니까?
비밀 번호 해싱의 보안은 정보가 비밀이 아닙니다. 이미 실제 암호, 즉 해시 값의 기초가되는 암호를 삭제했습니다. 나머지 해시는이 원본 데이터의 일종의 지문입니다. 보안은 해시에서 원본 데이터를 파생시킬 수 없다는 사실에서 비롯됩니다. 유일한 가능성은 가능한 모든 암호를 시도하고 어떤 암호가 동일한 해시를 생성하는지 확인하는 것입니다. 여기에 보안은 계산 상 매우 비싸고 유용한 시간 안에 성공하지 못할 것이라는 사실에서 비롯됩니다.
소금은 이미 미리 계산 된 알려진 해시 암호 집합을 사용하지 못하도록하기 위해 도입 된 것으로 공격자가 고유 한 소금으로 모든 가능한 암호를 실제로 다시 강요하도록합니다. 소금 자체는 비밀이 아니며, 해싱 알고리즘도 아니다.
요컨대, 그렇습니다. 그 값은 데이터베이스에 저장하는 것이 절대적으로 안전합니다.
crypt()에 의해 생성 된 해시는 특별히 저장됩니다. 암호 해싱 스키마가 무엇이든 누군가가 데이터베이스 내용을 보유하게되면 암호를 무차별 대입 할 수있게되며 암호 해시를 저장하지 않을 수있는 옵션이 없습니다. crypt()에 의해 적용된 알고리즘은 해시를 계산하는 데 상당한 시간이 걸리기 때문에 특별히 선택됩니다. 이것은 하나의 암호 만 테스트 할 때 분명하지 않지만 수천 개의 암호를 강요하는 것은 비실용적으로 느려집니다.
그러나 누군가가 이들 값 중 일부를 해독하기 위해 일반적인 비밀번호 목록을 테스트 할 수 없었습니까?
암호 저장 방법에 관계없이 언제든지 할 수 있습니다. crypt 함수는 이것을 막지는 못하지만 정말 느리게 만듭니다. 사용자가 정말로 일반적인 암호 (123456처럼)를 사용하면 세계에서 해싱 알고리즘이 그를 보호하지 못합니다.
간단한 암호를 허용하지 않고 올바른 해싱 알고리즘 (crypt() 제공)을 사용하면 암호를 보호하기 위해 최선을 다했습니다.
다른 사용자가 데이터베이스에 액세스 할 수있는 경우 소금을 사용할 수 있습니다. 데이터베이스에 저장하는 모든 사용자 암호에 다른 소금을 사용해야하기 때문입니다.
소금의 포인트는 무지개 테이블이 작동하지 않도록하기위한 것입니다. 개인은 암호를 결정하기 위해 password + salt의 모든 조합을 다시 해시해야합니다. 각 암호마다 다른 소금을 사용하므로 각 암호에 대해 수백만 개의 해시를 다시 생성해야합니다. 토굴에
좀 더 좋은 정보는 여기에서 찾을 수 있습니다 : Why does PHP crypt() prepend the salt to the hash?
이 데이터베이스는 안전하지 않습니다? – CompanyDroneFromSector7G