loginID, password, logTime과 같은 로그인 정보를 저장하는 테이블이 있습니다. 암호화 할 암호와 암호를 비교하는 두 가지 저장 프로 시저를 만듭니다. 암호를 암호화하고 비교하려면 키가 있어야합니다. 열쇠를 어디에 보관해야하는지 알고 싶습니다. 상점 절차 나 응용 프로그램에 넣으면 개발 팀에서 볼 수 있습니다. 그리고 열쇠를 지키기위한 모범 사례를 알고 싶습니다. 제발 조언.암호를 암호화하고 암호를 해독하기위한 키를 저장하는 위치
감사합니다.
암호를 암호화하지 않고 해시해야합니다. 그렇다면 키가 필요 없습니다.
암호를 저장하는 위치와 관계없이 궁극적으로 암호를 찾을 수 있습니다. 따라서 다른 개발자에게 숨기려면 작동하지 않습니다.
그러나 해시 암호에는 키가 필요합니다. 맞습니까? –
Sambath : 사실이 아닙니다. 해시 된 암호는 종종 "소금에 절인"되며, sha1과 같은 일부 암호화 해시 함수로 암호를 해싱하기 전에 암호에 임의의 접두사 (소금이라고 함)를 추가한다는 것을 의미합니다. 그런 다음 해쉬 된 소금 + 암호와 함께 소금을 저장합니다. 이것은 누군가가 무력이나 사전 공격을하는 것을 더 어렵게 만듭니다. –
더 강한 SHA1이 아닙니다. –
는 그 각각은 서로 다른 솔루션을 필요로 인증 자격 증명을 저장하기 위해 사용 - 다양한 사례가 있습니다 자격 증명 시스템에 사용자 로깅 경우
을, 다음 가장 좋은 방법은에서 암호를 저장하지 않는 것입니다 모든. 대신 비밀번호의 단방향 암호화 해시를 만들어 저장하십시오. 사용자가 로그인을 시도하면 제공된 비밀번호를 해시하고 결과를 저장된 해시와 비교합니다. 해시에는 사용자의 암호가 변경 될 때마다 변경되는 "소금"이 포함되어야합니다. 따라서 해시 코드가 시스템 해시 된 암호 파일을 도용하는 경우 해커 코드를 역 분개하기 위해 무차별 대입 공격을 적용하는 것이 더 어려워집니다.
타사 시스템에 로그인하는 사용자의 자격 증명 인 경우 시스템에 로그인하기 위해 사용자 암호의 다른 단방향 해시를 생성하여이를 암호화/암호화를위한 대칭 암호의 키로 사용할 수 있습니다. 저장된 사용자 자격 증명을 해독합니다. 다시 한번 핵심 원칙은 이 아니며은 사용자의 자격 증명을 해독하는 데 필요한 정보를 저장한다는 것입니다. 이 경우 키로 사용되는 해시를 저장하면 안됩니다.
자격 증명이 다른 시스템에서 자체를 인증하는 시스템의 경우 일반적인 해결 방법은 키 저장소를 사용하고이를 보호하기 위해 호스트 운영 체제와 잠금 해제에 사용되는 키 구를 사용하는 것입니다. (더 좋은 해결책이 있다면, 정말로 그것에 대해 듣고 싶습니다.)
사용자 비밀번호를 저장하거나 저장하는 것은 나쁜 생각입니다. 누군가가 침입 할 가능성이 항상 있기 때문입니다. 그들을 훔쳐. 암호가 암호화되어 있어도 해독 키는 어딘가에 저장해야합니다. 결정된 해커가이를 찾을 수 있습니다. 또는 신뢰할 수있는 관리자가 암호 및/또는 암호 해독 키를 공개하도록 설득 될 수 있습니다. 암호가 아닌 해시를 저장하면 데이터베이스 및/또는 응용 프로그램의 키 저장소가 손상된 경우에도 추가로 보호됩니다.
두 번째 부분은 많은 사용자가 많은 시스템에서 동일한 암호를 사용한다는 것입니다. 따라서 암호가 노출되도록 시스템이 손상된 경우 잠재적으로 다른 시스템의 사용자 계정을 노출하게됩니다.
이 주제에 관해서 몇 가지 질문이있었습니다 ... –