비밀번호가 안전한 데이터베이스에 저장되는 경우 비밀번호를 암호화해야하는 이유는 무엇입니까?

웹 서비스가 있습니다. 지금은 암호를 서버 의 MySQL 테이블에 일반 텍스트로 저장했습니다 . 나는 이것이 최선의 방법이 아니라는 것을 알고 있습니다.

비밀번호가 안전한 데이터베이스에 저장되는 경우 비밀번호를 암호화해야하는 이유는 무엇입니까? 누군가 내 데이터베이스를 해킹하면 모든 사람의 비밀번호를 얻습니다. 그러나 누군가 데이터를 삭제하는 등 누군가 내 데이터베이스에 들어가면 다른 문제가 있습니다.

내가 생각할 수있는 시나리오는 당신이 해킹 당했다는 것입니다. 몇 시간 전에 데이터베이스를 복원하면 모든 것이 정상입니다. 그러나 암호가 일반 텍스트 인 경우 ... 도둑이 모든 암호를 가지고 있으므로 모두 재설정해야합니다. 사용자에게 번거 로움.

비밀번호가 암호화 된 경우 이전 데이터베이스로 복원 할 수 있습니다. 이것이 올바른 생각입니까?

먼저, 읽기 / 쓰기보다 읽기 전용 액세스 권한이 더 자유로 워야합니다. 해커가 데이터에 액세스 할 수 있지만 편집 할 수는 없습니다.

그러나 더 중요한 것은 이것이 당신에 관한 것이 아닙니다. 누군가 데이터베이스에 대한 전체 액세스 권한이있는 경우 문제가 발생할 수 있습니다. 훨씬 더 중요한 것은 사용자의 데이터입니다.

데이터베이스를 복구해도 해커는 여전히 사용자 계정에 액세스 할 수 있습니다.

그리고 누가 다른 것을 알고 있습니까? Google에서 동일한 비밀번호를 사용하면 어떻게 되나요? 아니면 페이팔? 해커가 어머니의 성함 또는 신용 카드의 마지막 4 자리에 액세스 할 수 있다면 어떨까요?

다른 계정으로 가져 오면 어떻게 되나요? 사용자 지원 시스템을 통해 더 많은 정보를 얻기 위해 해커를 지나치지 마십시오 .

그냥 ... 그냥하지 마십시오. 그것은 사용자의 개인 정보이며 볼 필요가 없습니다. 그것은 또한 당신의 명성입니다. 암호화하십시오.

편집 : 하나의 추가 의견, 모든 미래의 독자가 모든 답변과 의견을 읽지 않도록 저장합니다 ...

(가장 엄격하게) 암호화하려는 경우 공개 / 개인 키 쌍 을 사용해야합니다 . 이는 좋지만 사용자와 사용자 모두에게 인생이 조금 더 어려워집니다.

더 간단하고 효과적인 해결책은 암호 를 무작위로 변경 하고 해시 하는 것입니다. 해싱만으로는 충분하지 않습니다. 사용자가 공통 암호를 사용하는 경우 간단한 인터넷 검색으로 쉽게 사용할 수있는 역 해싱 테이블에 표시됩니다.

해킹 당하면 백업에서 사이트를 복원하고 수정할 수 있습니다. 그러나 해커는 여전히 모든 사람의 암호를 가지고 있습니다! 비밀번호 테이블이 올바르게 해시되고 솔트 된 경우, 해당 서비스를 신속하게 보호 및 복원하는 것이 훨씬 쉬웠을 수있는 이러한 실제 사례 (Sony, Linked-in)가 문서화되어 있습니다.

그것은 당신이 생각하는 아마 좋은 생각 합니다 해킹 및 백업 전략을 설계하고 마음이 가정에 중요한 데이터를 암호화합니다. 그리고 보호해야 할 해커 만이 아닙니다. 불만을 품거나 부정직하거나 단서가없는 직원은 일반 텍스트 암호를 제공 할 수 있습니다.

해시가 없으면 암호를 변경할 때까지 모든 사람이 액세스를 비활성화해야합니다 (가능한 경우 모두에게 큰 골칫거리가 될 것임). 암호가 해시되고 소금에 절인 경우 웹 서비스를 복원 할 수 있으며 공격자가 사람들의 계정에 액세스하는 것이 훨씬 어려울 수 있습니다.

적절하게 해시 및 솔트 된 비밀번호는 기본적으로 단방향입니다. 해시 된 비밀번호에서 비밀번호를 쉽게 추측 할 수 없습니다. 서비스 제공 업체는 추측 할 수 없으므로 재설정 만 할 수 있습니다.

또한 Elin이 말했듯이 자체 해싱 (또는 암호화)을 시도하고 굴리지 마십시오. 표준 라이브러리를 사용하십시오.

그러나 누군가 내 데이터베이스에 들어가면 데이터를 삭제하는 등 다른 문제가 있습니다.

이 문제에 대해 아니에요 당신은 그것이 다른 모든 사용자에 대해 발생할 수있는 문제에 관하여,있다. 그것은 사이트에서 일하는 사람들이 그곳에 저장된 데이터를 남용하려는 유혹 (또는 더 나쁜 잠재적 책임)을 제거하는 것입니다.

사람들 이 다른 시스템에서 다른 암호를 사용해야 하더라도 실제로는 그렇지 않습니다 .

... 암호를 해시하기가 쉽기 때문에 업계 모범 사례를 따르지 않을 이유가 없습니다.

데이터 삭제와 같은 눈에 띄는 공격은 대개 아마추어의 일이며 걱정할 필요가 없습니다. 숙련 된 공격자가 가장 먼저해야 할 일 중 하나는 합법적 인 액세스를 시도하는 것입니다. 따라서 사용자가 사용한 원래 취약점을 패치하더라도 여전히 침입 할 수 있습니다. 그가 원하는 것을 성취합니다. 암호를 해시하지 않으면 그의 작업이 훨씬 쉬워 질 수 있습니다. 또한 미래의 악의적 인 행동을 탐지하고 격리하기가 더 어려워졌습니다.

또한 모든 절충안이 완전한 쉘 액세스를 제공하지는 않습니다. 침입자가 사용한 취약점이 users테이블 에 대한 읽기 전용 SQL 인젝션 인 경우 어떻게됩니까? 암호를 해시하지 않은 채로두면 거의 모든 액세스 권한이 부여됩니다.

이는 사용자 데이터를 보호해야 할 책임에 대한 다른 답변의 이유에 추가됩니다. 내 요점은, 당신이 잃을 무언가를 가진 사용자 만이 아닙니다.

질문 자체의 오류에 대한 답변을 여기에 게시해야합니다. 비밀번호를 암호화해야하는지 묻습니다. 아무도 암호를 암호화하지 않습니다. Firefox Sync 및 Roboform과 같은 서비스 및 프로그램을 제외하고는 아무도 암호를 암호화하는 것이 아닙니다.

정의를 살펴 보자.

암호화에서 암호화는 인증 된 당사자 만 읽을 수있는 방식으로 메시지 (또는 정보)를 인코딩하는 프로세스입니다.

그리고 해싱 :

해시 함수는 임의 길이의 데이터를 고정 길이의 데이터에 매핑하는 알고리즘입니다.

즉, 암호화는 양방향 변환이고 해싱은 단방향 변환이므로 나중에 볼 수 있도록 암호를 해독하지 않으면 암호화가 아닙니다.

또한 해시하지 마십시오. 소금 ! 비밀번호를 해시하기 전에이 전체 페이지를 읽으십시오.

OP가 지금 찾고있는 해싱 알고리즘에 관해서는 SHA-384 또는 SHA-512와 같은 고급 SHA-2 변형을 제안합니다.

그리고 라운드 해싱 을 사용해야 합니다. 한 번 해시하지 말고 여러 번 해시하십시오.

로그인 프로세스를보다 안전하게하려면 이 페이지 를 읽으 십시오.

둘째, 데이터베이스는 충분히 안전 할 수 없습니다. 보안 허점과 끊임없이 진화하는 위험이 항상 있습니다. 머피의 법칙을 따라야하며 항상 최악의 상황에 대비해야합니다.

pdr이 만드는 또 다른 요점 은 내가 말하는 다른 말입니다. 모든 웹 사이트에 대해 동일한 암호를 사용하는 사람들, 사회 공학을 사용하여 더 많은 정보를 얻는 등

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

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

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

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

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

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

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

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

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

암호를 두 번째 방어 계층 으로 "암호화"(실제로 "해시", 적절한 해싱 개념)해야합니다 . 이는 데이터베이스를 읽기 전용으로 엿본 공격자가 에스컬레이션하는 것을 방지하기위한 것입니다. 이를 읽기-쓰기 액세스로 바꾸고 정확하게 데이터를 변경하기 시작합니다. 읽기 전용 액세스 권한이있는 계정의 일부 SQL 주입 공격이나 폐기 된 하드 디스크 또는 오래된 백업 테이프를 쓰레기 수거통에서 검색하는 등 실제 상황에서는 읽기 전용 부분 위반이 발생합니다. 나는이 주제에 길이에 쓴 있다 .

암호를 해시하는 올바른 방법은 이 답변을 참조하십시오 . 여기에는 소금, 반복 및 무엇보다도 자신의 알고리즘을 발명 하지 않는 것이 포함됩니다 (수제 암호화는 재난의 확실한 제조법입니다).

다른 사람들의 말을 반복하지는 않지만 PHP 5.3.8 이상을 사용 한다고 가정하면 PHP 네이티브 bcrypt를 사용하여 비밀번호를 저장해야합니다. 이것은 PHP에 내장되어 있습니다. PHP 5.5를 사용한다면 최상의 암호 상수를 사용할 수 있습니다. 라이브러리를 사용하여 5.3.8 이상을 5.5처럼 작동하도록 만들 수도 있습니다.

스택 오버플로 질문 PHP에서 해싱 암호에 bcrypt를 어떻게 사용합니까? 그것을 설명하고 다른 답변은 더 설명합니다. 이 작업을 직접 수행하려고 애 쓰지 마십시오.

그 답변에 명시된 이유로 pdr의 답변에 동의합니다.

다음을 추가하겠습니다. 수행 하기 쉽고 일반적으로 모든 응용 프로그램의 모범 사례로 받아 들여 지기 때문에 수행해야 합니다. 보다 구체적으로, 영구 저장소에 쓰기 전에 암호는 항상 소금에 절이고 해시 해야합니다. 다음은 솔트의 중요성과 좋은 암호화 해시 (여러 대중적인 언어로 무료 소스 코드를 제공함)를 선택하는 것에 대한 좋은 참고 자료입니다 : https://crackstation.net/hashing-security.htm

소량의 추가 개발 시간은 사용자에게 제공하는 보호 기능과 개발자로서의 명성에 가치가 있습니다.

내가 생각할 수있는 시나리오는 당신이 해킹 당했다는 것입니다.

고려해야 할 또 다른 시나리오 : 누군가가 DBA를 미끄러 뜨리거나 다른 사람이 DB에서 선택 쿼리를 실행할 수있는 사람에게 $ 100를 지불하여 사용자의 암호를 제공합니다. 또는 사회 공학자들이 그렇게 할 인턴입니다.

그런 다음이 비밀번호를 사용하여 사용자의 Gmail 또는 상거래 사이트에 로그인합니다 (사람이 똑똑하지 않기 때문에-사이트 전체에서 동일한 비밀번호를 사용함).

그런 다음 irate 사용자는 회사에서 비밀번호를 노출 한 것으로 소송을 제기합니다.

NOBODY (회사 직원 포함)는 일반 텍스트 비밀번호를 읽을 수 있어야합니다. 이제까지. 이에 대한 합법적 인 비즈니스 또는 기술적 요구는 없습니다.

우선, 데이터베이스 관리자조차도 사용자의 비밀번호를 볼 수 없습니다. 관리자가 비밀번호를보고 사용자 계정에 로그인하기로 결정한 경우이를 해시하면이를 방지 할 수 있습니다.

글쎄, 아무도 이것을 언급하지 않은 것은 놀라운 일이지만 데이터베이스의 물리적 보안은 어떻습니까?

세계 최고의 IT 보안을 설정했지만 스토리지 미디어에 물리적으로 액세스 할 수있는 사람을 막을 수는 없습니다. 오늘 오후에 팀이 슈퍼 볼에서 우승하고 사무실 / 호스팅 제공 업체가있는 도시의 다운타운 지역에서 작은 폭동이 발생하면 어떻게됩니까? (미국의 두 개의 큰 IT 영역 인 Seattle vs. Denver라는 점을 감안할 때 저는 이것이 합리적이지 않다고 생각합니다). 폭도들이 건물로 밀려 들어 당국이 압도되는 동안 누군가가 일반 텍스트 암호가 들어있는 DB를 사용하여 일부 하드웨어를 가져 옵니까?

일부 고위 임원이 회사에서 자신의 위치를 ​​불법 주식 거래로 사용하고 있었기 때문에 Feds가 장비를 압류하고 압류하면 어떻게됩니까? 그런 다음 연준은이 암호를 사용하여 고객을 조사했지만 아무 잘못도 없었습니다. 그런 다음 그들이 당신 을 취약 하게 만든 것이 당신 이라는 것을 알고 있습니다 .

IT 부서에서 기존 드라이브를 인턴에게 "인계"하기 전에 예정된 교체 작업을 수행 할 때 DB를 보유한 기존 RAID 드라이브를 지우는 것을 잊어 버린 후 기숙사 룸메이트가 남은 것을 찾아서 " 팔아서 다시는 추적하지 않았습니까?

DB 서버가 마더 보드를 불면 IT가 새 서버로 이미지를 복원하고 기존 서버의 "사체"가 재활용 힙에 던져지면 어떻게됩니까? 이러한 드라이브는 여전히 양호하며 데이터는 여전히 존재합니다.

괜찮은 아키텍트는 나중에 방화벽과 운영 정책을 통해 보안이 "볼트"되는 것이 아니라는 것을 알고 있습니다. 보안은 처음부터 디자인의 중요한 부분이어야한다, 그 암호는 단방향, 해시 의미 결코 밖으로 암호화 (심지어 자신의 데이터 센터 내부), 결코 복구와 함께 전송되지 않습니다. 검색 할 수있는 모든 것이 손상 될 수 있습니다.

데이터베이스가 해킹당하는 경우를 제외하고 : 고객으로서 나는 당신이 내 비밀번호를 알고 싶지 않습니다. 요청에 따라 비밀번호를 쉽게 잡을 수 있다는 것을 알고 있지만 언제든지 원하는대로 쿼리 할 때 비밀번호를 사용하지 않으면 더 좋은 느낌을받습니다.

암호가 일반 텍스트로 저장된 경우 사용자와 해당 테이블에 대한 액세스 권한이있는 사용자에게 알려짐을 의미합니다. 사용자 및 비밀번호 구현에 대한 전체 아이디어는 시스템의 특정 세션이 개인 정보 보호 및 보안상의 이유로 해당 사람에게 속하도록하는 것입니다.

사람들의 그룹에 의해 사용자 이름 / 비밀번호가 알려진 경우, 사람을 명백하게 식별하는 것은 쓸모 없게되고 , 이는 신원 도용, 사기에 대한 많은 가능한 시나리오를 만듭니다.

암호를 읽을 수 없어도 암호를 확인할 수 있도록 비대칭 암호화 프로토콜을 사용하여 암호를 저장하는 이유가 여기에 있습니다.

질문에 근본적인 결함이 있다고 생각합니다. 사실 "보안 데이터베이스"와 같은 것은 없습니다. 악의적 인 사용자가 서버의 임의의 데이터에 액세스 할 수있는 시스템 어딘가에 결함이있는 것으로 간주해야합니다. Heartbleed 는 훌륭한 사례로, 연구원들에 의해 발견되기 전에 2 년 이상 야생에 있었던 착취였습니다. 데이터를 보호하기 위해 수행하는 방법을 아는 모든 작업을 수행했을 수도 있지만 서버에서 사용중인 다른 모든 소프트웨어 조각과 이들이 상호 작용하는 복잡한 방법을 설명 할 수는 없습니다.

누군가 당신에게 관심을 가지면 해킹 당할 것 입니다. 처음에는 해킹 당하지 않도록 최선을 다하고 가능한 한 많은 장애물을 배치하여 발생할 때 발생하는 피해를 완화하는 것이 중요합니다. 비밀번호를 해시하십시오. 그렇게 설정하는 것은 어렵지 않으며 사용자는 개인 정보를 심각하게 고려하지 않음으로써 사용자에게 서비스를 제공하지 않습니다. 야후 , 소니 , 또는 대상 과 같은 회사보다 해킹당한 회사보다 악의적 인 공격에 더 잘 보호된다고 생각하는 것이 가장 중요 합니다.