웹 서비스가 있습니다. 지금은 암호를 서버 의 MySQL 테이블에 일반 텍스트로 저장했습니다 . 나는 이것이 최선의 방법이 아니라는 것을 알고 있습니다.
비밀번호가 안전한 데이터베이스에 저장되는 경우 비밀번호를 암호화해야하는 이유는 무엇입니까? 누군가 내 데이터베이스를 해킹하면 모든 사람의 비밀번호를 얻습니다. 그러나 누군가 데이터를 삭제하는 등 누군가 내 데이터베이스에 들어가면 다른 문제가 있습니다.
내가 생각할 수있는 시나리오는 당신이 해킹 당했다는 것입니다. 몇 시간 전에 데이터베이스를 복원하면 모든 것이 정상입니다. 그러나 암호가 일반 텍스트 인 경우 … 도둑이 모든 암호를 가지고 있으므로 모두 재설정해야합니다. 사용자에게 번거 로움.
비밀번호가 암호화 된 경우 이전 데이터베이스로 복원 할 수 있습니다. 이것이 올바른 생각입니까?
답변
먼저, 읽기 / 쓰기보다 읽기 전용 액세스 권한이 더 자유로 워야합니다. 해커가 데이터에 액세스 할 수 있지만 편집 할 수는 없습니다.
그러나 더 중요한 것은 이것이 당신에 관한 것이 아닙니다. 누군가 데이터베이스에 대한 전체 액세스 권한이있는 경우 문제가 발생할 수 있습니다. 훨씬 더 중요한 것은 사용자의 데이터입니다.
데이터베이스를 복구해도 해커는 여전히 사용자 계정에 액세스 할 수 있습니다.
그리고 누가 다른 것을 알고 있습니까? Google에서 동일한 비밀번호를 사용하면 어떻게 되나요? 아니면 페이팔? 해커가 어머니의 성함 또는 신용 카드의 마지막 4 자리에 액세스 할 수 있다면 어떨까요?
다른 계정으로 가져 오면 어떻게 되나요? 사용자 지원 시스템을 통해 더 많은 정보를 얻기 위해 해커를 지나치지 마십시오 .
그냥 … 그냥하지 마십시오. 그것은 사용자의 개인 정보이며 볼 필요가 없습니다. 그것은 또한 당신의 명성입니다. 암호화하십시오.
편집 : 하나의 추가 의견, 모든 미래의 독자가 모든 답변과 의견을 읽지 않도록 저장합니다 …
(가장 엄격하게) 암호화하려는 경우 공개 / 개인 키 쌍 을 사용해야합니다 . 이는 좋지만 사용자와 사용자 모두에게 인생이 조금 더 어려워집니다.
더 간단하고 효과적인 해결책은 암호 를 무작위로 변경 하고 해시 하는 것입니다. 해싱만으로는 충분하지 않습니다. 사용자가 공통 암호를 사용하는 경우 간단한 인터넷 검색으로 쉽게 사용할 수있는 역 해싱 테이블에 표시됩니다.
답변
해킹 당하면 백업에서 사이트를 복원하고 수정할 수 있습니다. 그러나 해커는 여전히 모든 사람의 암호를 가지고 있습니다! 비밀번호 테이블이 올바르게 해시되고 솔트 된 경우, 해당 서비스를 신속하게 보호 및 복원하는 것이 훨씬 쉬웠을 수있는 이러한 실제 사례 (Sony, Linked-in)가 문서화되어 있습니다.
그것은 당신이 생각하는 아마 좋은 생각 합니다 해킹 및 백업 전략을 설계하고 마음이 가정에 중요한 데이터를 암호화합니다. 그리고 보호해야 할 해커 만이 아닙니다. 불만을 품거나 부정직하거나 단서가없는 직원은 일반 텍스트 암호를 제공 할 수 있습니다.
해시가 없으면 암호를 변경할 때까지 모든 사람이 액세스를 비활성화해야합니다 (가능한 경우 모두에게 큰 골칫거리가 될 것임). 암호가 해시되고 소금에 절인 경우 웹 서비스를 복원 할 수 있으며 공격자가 사람들의 계정에 액세스하는 것이 훨씬 어려울 수 있습니다.
적절하게 해시 및 솔트 된 비밀번호는 기본적으로 단방향입니다. 해시 된 비밀번호에서 비밀번호를 쉽게 추측 할 수 없습니다. 서비스 제공 업체는 추측 할 수 없으므로 재설정 만 할 수 있습니다.
또한 Elin이 말했듯이 자체 해싱 (또는 암호화)을 시도하고 굴리지 마십시오. 표준 라이브러리를 사용하십시오.
답변
그러나 누군가 내 데이터베이스에 들어가면 데이터를 삭제하는 등 다른 문제가 있습니다.
이 문제에 대해 아니에요 당신은 그것이 다른 모든 사용자에 대해 발생할 수있는 문제에 관하여,있다. 그것은 사이트에서 일하는 사람들이 그곳에 저장된 데이터를 남용하려는 유혹 (또는 더 나쁜 잠재적 책임)을 제거하는 것입니다.
사람들 이 다른 시스템에서 다른 암호를 사용해야 하더라도 실제로는 그렇지 않습니다 .
… 암호를 해시하기가 쉽기 때문에 업계 모범 사례를 따르지 않을 이유가 없습니다.
답변
데이터 삭제와 같은 눈에 띄는 공격은 대개 아마추어의 일이며 걱정할 필요가 없습니다. 숙련 된 공격자가 가장 먼저해야 할 일 중 하나는 합법적 인 액세스를 시도하는 것입니다. 따라서 사용자가 사용한 원래 취약점을 패치하더라도 여전히 침입 할 수 있습니다. 그가 원하는 것을 성취합니다. 암호를 해시하지 않으면 그의 작업이 훨씬 쉬워 질 수 있습니다. 또한 미래의 악의적 인 행동을 탐지하고 격리하기가 더 어려워졌습니다.
또한 모든 절충안이 완전한 쉘 액세스를 제공하지는 않습니다. 침입자가 사용한 취약점이 users테이블 에 대한 읽기 전용 SQL 인젝션 인 경우 어떻게됩니까? 암호를 해시하지 않은 채로두면 거의 모든 액세스 권한이 부여됩니다.
이는 사용자 데이터를 보호해야 할 책임에 대한 다른 답변의 이유에 추가됩니다. 내 요점은, 당신이 잃을 무언가를 가진 사용자 만이 아닙니다.
답변
질문 자체의 오류에 대한 답변을 여기에 게시해야합니다. 비밀번호를 암호화해야하는지 묻습니다. 아무도 암호를 암호화하지 않습니다. Firefox Sync 및 Roboform과 같은 서비스 및 프로그램을 제외하고는 아무도 암호를 암호화하는 것이 아닙니다.
정의를 살펴 보자.
암호화에서 암호화는 인증 된 당사자 만 읽을 수있는 방식으로 메시지 (또는 정보)를 인코딩하는 프로세스입니다.
그리고 해싱 :
해시 함수는 임의 길이의 데이터를 고정 길이의 데이터에 매핑하는 알고리즘입니다.
즉, 암호화는 양방향 변환이고 해싱은 단방향 변환이므로 나중에 볼 수 있도록 암호를 해독하지 않으면 암호화가 아닙니다.
또한 해시하지 마십시오. 소금 ! 비밀번호를 해시하기 전에이 전체 페이지를 읽으십시오.
OP가 지금 찾고있는 해싱 알고리즘에 관해서는 SHA-384 또는 SHA-512와 같은 고급 SHA-2 변형을 제안합니다.
그리고 라운드 해싱 을 사용해야 합니다. 한 번 해시하지 말고 여러 번 해시하십시오.
로그인 프로세스를보다 안전하게하려면 이 페이지 를 읽으 십시오.
둘째, 데이터베이스는 충분히 안전 할 수 없습니다. 보안 허점과 끊임없이 진화하는 위험이 항상 있습니다. 머피의 법칙을 따라야하며 항상 최악의 상황에 대비해야합니다.
pdr이 만드는 또 다른 요점 은 내가 말하는 다른 말입니다. 모든 웹 사이트에 대해 동일한 암호를 사용하는 사람들, 사회 공학을 사용하여 더 많은 정보를 얻는 등
답변
여기에는 중요한 원칙이 있습니다. 사용자 비밀번호를 아는 업체는 한 명뿐입니다. 그것은 사용자입니다. 그들의 아내 / 남편, 의사 또는 신부가 아닙니다.
여기에는 사용중인 서비스를 담당하는 프로그래머, 데이터베이스 관리자 또는 시스템 기술자가 포함되지 않습니다. 프로그래머가 사용자가 실제로 암호를 알고 있다는 사실을 증명해야 할 책임이 있기 때문에 문제가 발생합니다. 이는 순수한 방법으로 해결하기가 쉽지 않은 문제입니다.
순수한 해결책은 사용자에게 예측할 수없는 새로운 데이터로 문제를 제기 한 다음이 데이터와 암호를 기반으로 응답을 반환하는 메커니즘을 보유하는 것입니다. 이를 구현하는 한 가지 방법은 사용자에게 새로 생성 된 일부 데이터에 디지털 서명을 디지털 서명하도록 요청하는 것이며, 원래 계정을 만들 때 사용한 것과 동일한 암호화 키 쌍을 사용했음을 수학적으로 증명할 수 있습니다.
실제로 순수한 솔루션에는 실질적인 클라이언트 측 인프라 및 처리가 필요하며 많은 웹 사이트의 경우 데이터 보호에 적합하지 않은 경우가 많습니다.
더 일반적인 해결책은 다음과 같습니다.
애플리케이션에서 비밀번호가 처음 수신되는 시점에서 비밀번호는 애플리케이션의 임의의 ‘소금’값과 함께 해시 함수로 전달됩니다.
그런 다음 원래 문자열을 메모리에 덮어 쓰고이 시점부터 솔트 해시는 데이터베이스에 저장되거나 데이터베이스 레코드와 비교됩니다.
여기서 보안을 제공하는 주요 측면은 다음과 같습니다.
- 해시에 대한 지식은 인증을 직접 제공하지 않습니다.
- 해시에서 비밀번호를 역으로 계산하는 것은 실용적이지 않습니다.
- 레인보우 테이블 (긴 암호 목록 및 계산 된 해시)을 사용하는 것은 결과 해시가 사용자 이름과 암호 모두에 의존하기 때문에 더욱 어려워집니다.
답변
암호를 두 번째 방어 계층 으로 “암호화”(실제로 “해시”, 적절한 해싱 개념)해야합니다 . 이는 데이터베이스를 읽기 전용으로 엿본 공격자가 에스컬레이션하는 것을 방지하기위한 것입니다. 이를 읽기-쓰기 액세스로 바꾸고 정확하게 데이터를 변경하기 시작합니다. 읽기 전용 액세스 권한이있는 계정의 일부 SQL 주입 공격이나 폐기 된 하드 디스크 또는 오래된 백업 테이프를 쓰레기 수거통에서 검색하는 등 실제 상황에서는 읽기 전용 부분 위반이 발생합니다. 나는이 주제에 길이에 쓴 있다 .
암호를 해시하는 올바른 방법은 이 답변을 참조하십시오 . 여기에는 소금, 반복 및 무엇보다도 자신의 알고리즘을 발명 하지 않는 것이 포함됩니다 (수제 암호화는 재난의 확실한 제조법입니다).