PHP 암호를위한 보안 해시 및 솔트

질문 : PHP 암호를위한 보안 해시 및 솔트

---

현재 MD5는 부분적으로 안전하지 않다고합니다. 이를 고려하여 암호 보호에 사용할 메커니즘을 알고 싶습니다.

이 질문 은 "이중 해싱"이 암호를 한 번만 해싱하는 것보다 덜 안전합니까? 여러 번 해싱하는 것이 좋은 생각 일 수 있지만 개별 파일에 대한 암호 보호를 구현하는 방법은 무엇입니까? 소금 사용을 제안합니다.

PHP를 사용하고 있습니다. 안전하고 빠른 암호 암호화 시스템을 원합니다. 암호를 백만 번 해시하는 것이 더 안전 할 수 있지만 느릴 수도 있습니다. 속도와 안전 사이의 균형을 잘 잡는 방법은 무엇입니까? 또한 결과가 일정한 수의 문자를 갖는 것을 선호합니다.

또한 데이터베이스에 두 개의 필드를 저장해야합니까 (예 : MD5를 사용하는 필드와 SHA를 사용하는 필드)? 그것이 더 안전할까요 아니면 안전하지 않을까요?

충분히 명확하지 않은 경우 사용할 해싱 기능과 안전하고 빠른 암호 보호 메커니즘을 갖기 위해 좋은 솔트를 선택하는 방법을 알고 싶습니다.

내 질문을 다루지 않는 관련 질문 :

PHP에서 SHA와 MD5의 차이점은 무엇입니까
간단한 암호 암호화
asp.net에 대한 키, 암호를 저장하는 안전한 방법
Tomcat 5.5에서 솔트 암호를 어떻게 구현합니까?

답변

---

면책 조항 :이 답변은 2008 년에 작성되었습니다.

그 이후로 PHP는 password_hash 및 password_verify 를 제공했으며 도입 이후 권장되는 암호 해싱 및 확인 방법입니다.

대답의 이론은 여전히 좋은 읽기입니다.

• 사용자가 암호로 입력 할 수있는 문자를 제한하지 마십시오. 바보 만이 일을합니다.
• 암호의 길이를 제한하지 마십시오. 사용자가 supercalifragilisticexpialidocious가 포함 된 문장을 원하는 경우 사용하는 것을 막지 마십시오.
• 암호에서 HTML 및 특수 문자를 제거하거나 이스케이프하지 마십시오.
• 사용자의 암호를 일반 텍스트로 저장하지 마십시오.
• 사용자가 암호를 잃어 버리고 임시로 보낸 경우를 제외하고 는 절대로 사용자에게 이메일을 보내지 마십시오.
• 절대로 어떤 방식 으로든 암호를 기록하지 마십시오.
• SHA1 또는 MD5 또는 SHA256으로 비밀번호를 해시하지 마십시오! 최신 크래커 는 초당 600 억 및 180 억 해시를 초과 할 수 있습니다 (각각).
• bcrypt와 hash () 의 원시 출력을 혼합하지 말고 16 진 출력을 사용하거나 base64_encode하십시오. (이것은 보안을 심각하게 약화시킬 수 \0 을 포함 할 수있는 모든 입력에 적용됩니다.)

• 가능한 경우 scrypt를 사용하십시오. 할 수 없다면 bcrypt.
• SHA2 해시와 함께 bcrypt 또는 scrypt를 사용할 수없는 경우 PBKDF2를 사용하십시오.
• 데이터베이스가 손상되면 모든 사람의 비밀번호를 재설정합니다.
• 적절한 최소 8-10 자 길이를 구현하고 최소 1 개의 대문자, 1 개의 소문자, 숫자 및 기호가 필요합니다. 이렇게하면 암호의 엔트로피가 향상되어 해독하기가 더 어려워집니다. (토론에 대해서는 "좋은 암호는 무엇입니까?"섹션을 참조하십시오.)

해싱 암호의 목적은 간단합니다. 데이터베이스를 손상시켜 사용자 계정에 대한 악의적 인 액세스를 방지하는 것입니다. 따라서 암호 해싱의 목표는 일반 텍스트 암호를 계산하는 데 너무 많은 시간과 비용을 들여 해커 나 크래커를 방지하는 것입니다. 그리고 시간 / 비용은 당신의 무기고에서 최고의 억제력입니다.

사용자 계정에 대해 훌륭하고 강력한 해시를 원하는 또 다른 이유는 시스템의 모든 암호를 변경할 수있는 충분한 시간을 제공하는 것입니다. 데이터베이스가 손상된 경우 데이터베이스의 모든 암호를 변경하지 않으면 최소한 시스템을 잠글 수있는 충분한 시간이 필요합니다.

Whitehat Security의 CTO 인 Jeremiah Grossman은 최근의 비밀번호 복구 후 비밀번호 보호를 무차별 적으로 차단해야하는 White Hat Security 블로그에 다음과 같이 말했습니다.

흥미롭게도이 악몽을 살아 가면서 나는 암호 크래킹, 저장 및 복잡성에 대해 몰랐던 많은 것을 배웠습니다. 암호 저장이 암호 복잡성보다 훨씬 더 중요한 이유를 알게되었습니다. 암호가 어떻게 저장되는지 모르는 경우 실제로 의존 할 수있는 것은 복잡성뿐입니다. 이것은 암호 및 암호화 전문가에게는 상식 일 수 있지만, 평균적인 InfoSec 또는 웹 보안 전문가에게는 매우 의심 스럽습니다.

 

엔트로피 . (내가 Randall의 관점에 완전히 동의하는 것은 아닙니다.)

요컨대 엔트로피는 암호에 얼마나 많은 변화가 있는지입니다. 암호가 로마자 소문자 만 사용하면 26 자입니다. 그다지 변이가 아닙니다. 36 자의 영숫자 암호가 더 좋습니다. 그러나 기호와 함께 대문자와 소문자를 허용하는 것은 대략 96 자입니다. 그것은 단순한 편지보다 훨씬 낫습니다. 한 가지 문제는 암호를 기억하기 쉽게 만들기 위해 패턴을 삽입하여 엔트로피를 줄이는 것입니다. 이런!

암호 엔트로피는 쉽게 근사화 됩니다. 전체 범위의 ASCII 문자 (대략 96 개의 입력 가능 문자)를 사용하면 문자 당 6.6의 엔트로피가 생성되며, 이는 암호의 8 자에서 향후 보안을 위해 여전히 너무 낮습니다 (52.679 비트의 엔트로피). 그러나 좋은 소식은 긴 암호와 유니 코드 문자가있는 암호는 실제로 암호의 엔트로피를 증가시켜 크래킹하기 어렵게 만든다는 것입니다.

Crypto StackExchange 사이트에서 암호 엔트로피에 대한 더 긴 논의가 있습니다. 좋은 Google 검색은 또한 많은 결과를 표시합니다.

코멘트에서 나는 X 많은 문자, 숫자, 기호 등으로 X 길이의 암호 정책을 적용, 실제로 암호 방식은 예측함으로써 엔트로피 감소시킬 수 있다고 지적 @popnoodles, 함께 이야기했다. 동의합니다. Randomess는 가능한 한 진정으로 무작위로 항상 가장 안전하지만 기억에 남지 않는 솔루션입니다.

내가 말할 수있는 한, 세계 최고의 암호를 만드는 것은 Catch-22입니다. 기억에 남지 않거나, 너무 예측 가능하거나, 너무 짧거나, 너무 많은 유니 코드 문자 (Windows / 모바일 장치에서 입력하기 어렵 음), 너무 긴 등입니다. 우리의 목적에 맞는 암호는 진정으로 충분하지 않습니다. 따라서 우리는 그들을 보호해야합니다. Fort Knox에있었습니다.

Bcrypt 및 scrypt 는 현재 모범 사례입니다. Scrypt 는 시간이 지나면 bcrypt보다 나을 것이지만 Linux / Unix 또는 웹 서버의 표준으로 채택되지 않았으며 아직 게시 된 알고리즘에 대한 심층적 인 리뷰도 없었습니다. 그러나 여전히 알고리즘의 미래는 유망 해 보입니다. Ruby로 작업 하는 경우 도움이 될 scrypt gem 이 있으며 Node.js에는 이제 자체 scrypt 패키지가 있습니다. Scrypt 확장 또는 Libsodium 확장을 통해 PHP에서 Scrypt를 사용할 수 있습니다 (둘 다 PECL에서 사용 가능).

bcrypt를 사용하는 방법을 이해하고 싶으면 crypt 함수에 대한 문서를 읽어 보거나 좋은 래퍼를 찾거나 더 많은 레거시 구현을 위해 PHPASS 와 같은 것을 사용 하는 것이 좋습니다. 15-18이 아닌 경우 최소 12 라운드의 bcrypt를 권장합니다.

나는 bcrypt가 가변 비용 메커니즘과 함께 blowfish의 주요 일정만을 사용한다는 것을 알았을 때 bcrypt 사용에 대한 마음을 바꿨습니다. 후자는 이미 값 비싼 blowfish의 주요 일정을 늘림으로써 암호를 무차별 대입하는 비용을 증가시킬 수 있습니다.

나는이 상황을 더 이상 상상할 수 없다. PHPASS 는 PHP 3.0.18에서 5.3까지 지원하므로 상상할 수있는 거의 모든 설치에서 사용할 수 있습니다. 환경에서 bcrypt를 지원하는지 확실하지 않은 경우 사용해야합니다.

그러나 bcrypt 또는 PHPASS를 전혀 사용할 수 없다고 가정하십시오. 그럼 뭐야?

환경 / 애플리케이션 / 사용자 인식이 허용 할 수있는 최대 라운드 수로 PDKBF2 를 구현해보십시오. 내가 권장하는 가장 낮은 숫자는 2500 라운드입니다. 또한 작업을 재현하기 어렵게 만들 수있는 경우 hash_hmac () 을 사용해야합니다.

PHP 5.5는 bcrypt로 작업 할 때 발생하는 모든 고통을 없애 주는 완전한 암호 보호 라이브러리입니다. 우리 대부분은 대부분의 일반적인 환경, 특히 공유 호스트에서 PHP 5.2 및 5.3을 사용하고 있지만 @ircmaxell은 PHP 5.3.7과 역 호환되는 향후 API에 대한 호환성 계층을 구축했습니다.

실제로 해시 된 암호를 해독 하는 데 필요한 계산 능력은 존재하지 않습니다. 컴퓨터가 암호를 "크래킹"하는 유일한 방법은 암호를 다시 만들고 보안에 사용되는 해싱 알고리즘을 시뮬레이션하는 것입니다. 해시의 속도는 무차별 대입 능력과 선형 적으로 관련됩니다. 더 나쁜 것은 대부분의 해시 알고리즘을 쉽게 병렬화하여 더 빠르게 수행 할 수 있다는 것입니다. 이것이 bcrypt 및 scrypt와 같은 비용이 많이 드는 체계가 중요한 이유입니다.

당신이 눈 앞에 사용자를 보호하기 위해 최선의 노력을해야합니다 있도록 가능한 모든 공격 위협이나 도로를 예견하고, 수 없습니다. 당신이 경우에, 당신도 당신에게있는 거 책임을 너무 늦기 때까지 공격 한 사실을 그리워 ... 그리고 있습니다. 그러한 상황을 피하려면 편집증적인 행동을 취하십시오. 자신의 소프트웨어를 (내부적으로) 공격하고 사용자 자격 증명을 훔치거나 다른 사용자의 계정을 수정하거나 데이터에 액세스하려고 시도합니다. 시스템 보안을 테스트하지 않으면 자신 외에 다른 사람을 비난 할 수 없습니다.

마지막으로 저는 암호학자가 아닙니다. 내가 말한 것은 내 의견이지만, 나는 그것이 좋은 상식과 많은 독서에 근거한 것이라고 생각합니다. 가능한 한 편집증이 있고, 가능한 한 침입하기 어렵게 만든 다음, 여전히 걱정이되는 경우 화이트 햇 해커 또는 암호 전문가에게 연락하여 코드 / 시스템에 대해 말하는 것을 확인하십시오.

출처 : https://stackoverflow.com/questions/401656/secure-hash-and-salt-for-php-passwords