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

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

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

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

1. 해싱 메커니즘은 PHP에서 사용할 수 있어야합니다
2. 안전해야합니다
3. 소금을 사용할 수 있습니다 (이 경우 모든 소금이 똑같이 좋습니까? 좋은 소금을 생성하는 방법이 있습니까?)

또한 데이터베이스에 두 개의 필드 (예 : MD5를 사용하는 필드와 SHA를 사용하는 필드)를 저장해야합니까? 더 안전하거나 안전하지 않습니까?

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

내 질문에 잘 맞지 않는 관련 질문 :

PHP에서 SHA와 MD5의 차이점
단순 암호 암호화
asp.net의 키, 암호를 안전하게 저장하는
방법 Tomcat 5.5에서 소금에 절인 암호를 어떻게 구현 하시겠습니까?

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

그 이후로, PHP는 우리에게 주신 password_hash하고 password_verify자신의 도입 이후, 그들은 권장 암호 해싱 및 확인 방법, 그리고.

대답의 이론은 여전히 ​​잘 읽습니다.

TL; DR

하지마

• 사용자가 비밀번호로 입력 할 수있는 문자를 제한하지 마십시오. 바보 만이 일을합니다.
• 비밀번호 길이를 제한하지 마십시오. 사용자가 supercalifragilisticexpialidocious가 포함 된 문장을 원한다면 사용하지 마십시오.
• 비밀번호에서 HTML 및 특수 문자를 제거하거나 이스케이프 처리하지 마십시오.
• 사용자의 비밀번호를 일반 텍스트로 저장하지 마십시오.
• 비밀번호를 분실 한 경우를 제외하고 사용자에게 비밀번호를 이메일로 보내지 말고 임시 비밀번호를 보냈습니다.
• 절대 어떤 식 으로든 비밀번호를 기록하지 마십시오.
• SHA1 또는 MD5 또는 심지어 SHA256으로 비밀번호를 해시하지 마십시오 ! 현대 크래커 는 각각 60-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 또는 웹 보안 전문가에게는 의심의 여지가 있습니다.

(엠파 시스 광산)

어쨌든 좋은 암호 는 무엇입니까 ?

엔트로피 . (난 랜달의 관점에 전적으로 동의하지는 않는다.)

간단히 말해서, 엔트로피는 암호 내에 얼마나 많은 변화가 있는지입니다. 암호가 소문자 로마자이면 26 자입니다. 큰 차이는 없습니다. 영숫자 암호는 36 자로 더 좋습니다. 그러나 기호와 함께 대소 문자를 허용하는 것은 대략 96 자입니다. 그것은 편지보다 훨씬 낫습니다. 한 가지 문제는 암호를 기억하기 쉽게하기 위해 엔트로피를 줄이는 패턴을 삽입하는 것입니다. 죄송합니다!

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

Crypto StackExchange 사이트 에서 암호 엔트로피에 대한 자세한 설명이 있습니다. 좋은 Google 검색은 많은 결과를 낳습니다.

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

내가 알 수있는 한 세계 최고의 암호를 만드는 것은 Catch-22입니다. 기억하기 어렵고, 예측 가능하고, 짧고, 너무 많은 유니 코드 문자 (Windows / 모바일 장치에서 입력하기 어렵다), 너무 길다. 암호는 실제 용도에 충분하지 않으므로 암호를 보호해야합니다. 포트 녹스에있었습니다.

모범 사례

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

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

나는 bcrypt가 가변 비용 메커니즘으로 복어의 주요 일정 만 사용한다는 것을 알았을 때 bcrypt 사용에 대한 마음을 바꿨습니다. 후자는 복어의 이미 비싼 키 일정을 늘려 암호를 무차별 처리하는 비용을 증가시킵니다.

평균 관행

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

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

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

미래의 관행

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

암호화 요약 및 면책

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

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

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

훨씬 짧고 안전한 답변- 비밀번호 메커니즘을 전혀 쓰지 말고 검증 된 메커니즘을 사용하십시오.

• PHP 5.5 이상 : password_hash () 는 좋은 품질이며 PHP 코어의 일부입니다.
• 이전 PHP 버전 : OpenWall의 phpass 라이브러리는 WordPress, Drupal 등에 사용되는 대부분의 사용자 정의 코드보다 훨씬 낫습니다.

대부분의 프로그래머에게는 취약점을 도입하지 않고 암호화 관련 코드를 안전하게 작성할 수있는 전문 지식이 없습니다.

빠른 자체 테스트 : 비밀번호 확장이란 무엇이며 얼마나 많은 반복을 사용해야합니까? 당신이 답을 모른다면, 당신은 사용해야 password_hash()스트레칭 암호가 현재 암호 메커니즘의 중요한 기능입니다으로 인해 더 빠른 CPU와의 사용, GPU가 및 FPGA를 의 속도로 암호를 해독하기 위해 초당 추측 수십억 GPU는 ( ).

예를 들어, 5 대의 데스크탑 PC에 설치된 25 개의 GPU를 사용하여 6 시간 내에 8 자의 Windows 암호를 모두 해독 할 수 있습니다 . 이는 특수 문자를 포함하여 모든 8 자 Windows 암호를 열거하고 확인하는 무차별 강제이며 사전 공격이 아닙니다. 2018 년 기준으로, 2018 년 현재 GPU를 더 적게 사용하거나 25 개의 GPU로 더 빨리 크랙 할 수 있습니다.

일반 CPU에서 실행되는 매우 빠른 Windows 암호에 대한 레인보우 테이블 공격도 많이 있습니다. Windows 10에서도 Windows가 여전히 암호를 변경 하거나 확장하지 않기 때문입니다 . Microsoft와 같은 실수를하지 마십시오!

또한보십시오:

• 왜 password_hash()또는 phpass최선의 방법 인지에 대한 훌륭한 답변 .
• bcrypt, scrypt 및 PBKDF2를 포함한 주요 알고리즘에 대해 권장되는 '작업 요소'(반복 횟수)를 제공하는 좋은 블로그 기사 .

암호 해시를 두 가지 방법으로 저장하지 않을 것입니다. 시스템이 사용중인 해시 알고리즘 중 가장 약한 것보다 약하기 때문입니다.

PHP 5.5부터 PHP는 암호 해시 및 암호 확인을위한 간단하고 안전한 기능을 가지고 있습니다 : password_hash () 및 password_verify ()

$password = 'anna';
$hash = password_hash($password, PASSWORD_DEFAULT);
$expensiveHash = password_hash($password, PASSWORD_DEFAULT, array('cost' => 20));

password_verify('anna', $hash); //Returns true
password_verify('anna', $expensiveHash); //Also returns true
password_verify('elsa', $hash); //Returns false

때 password_hash()사용되며, 이는 임의의 염을 생성하고 (비용 및 사용되는 알고리즘. 함께) 출력 된 해시를 포함하고 password_verify()그 해시를 판독하여 사용하는 염 및 암호화 방식을 결정하고, 제공하는 평문의 패스워드에 대한 검증하고 그것을.

제공된 PASSWORD_DEFAULTPHP 버전의 기본 해싱 알고리즘을 사용하도록 PHP에 지시합니다. 정확히 어떤 알고리즘을 의미하는지는 향후 버전에서 시간이 지남에 따라 변경되어 항상 가장 강력한 알고리즘 중 하나가 될 것입니다.

비용을 높이면 (기본값은 10) 해시가 무차별 대입이 어려워 지지만 해시를 생성하고 암호를 확인하는 것이 서버의 CPU에 더 효과적입니다.

기본 해싱 알고리즘이 변경 될 수 있지만 사용 된 알고리즘이 해시에 저장되어 password_verify()선택 되기 때문에 이전 해시는 계속해서 잘 확인 됩니다.

질문에 대한 답변이 있지만 해싱에 사용되는 솔트는 무작위이며 첫 번째 답변에서 제안한 이메일 주소와 달라야한다는 점을 반복하고 싶습니다.

자세한 설명은 http://www.pivotalsecurity.com/blog/password-hashing-salt-should-it-be-random/에서 확인할 수 있습니다 .

최근에 무작위 비트로 소금에 절인 암호 해시가 추측 가능한 소금이나 소금으로 소금에 절인 암호 해시보다 안전한지에 대한 토론이있었습니다. 보자 : 무작위 소금을 저장하는 시스템뿐만 아니라 암호를 저장하는 시스템이 손상되면 공격자는 소금이 무작위이든 아니든 상관없이 해시와 소금에 액세스 할 수 있습니다. 공격자는 미리 계산 된 레인보우 테이블을 생성하여 해시를 해독 할 수 있습니다. 여기에 흥미로운 부분이 있습니다. 미리 계산 된 테이블을 생성하는 것은 그리 쉬운 일이 아닙니다. WPA 보안 모델을 예로 들어 보겠습니다. WPA 암호는 실제로 무선 액세스 포인트로 전송되지 않습니다. 대신 SSID (Linksys, Dlink 등의 네트워크 이름)로 해시됩니다. 이것이 어떻게 작동하는지에 대한 아주 좋은 설명이 여기 있습니다. 해시에서 비밀번호를 검색하려면 솔트 (네트워크 이름)뿐만 아니라 암호도 알아야합니다. Church of Wifi는 이미 1000 개의 상위 SSID와 약 1 백만 개의 비밀번호를 가진 사전 계산 된 해시 테이블을 가지고 있습니다. 모든 테이블의 크기는 약 40GB입니다. 사이트에서 읽을 수 있듯이 누군가가 3 일 동안 15 개의 FGPA 어레이를 사용하여 이러한 테이블을 생성했습니다. 피해자가 SSID를 "a387csf3"로 사용하고 암호를 "123456"으로 사용한다고 가정하면 해당 테이블에 의해 크랙됩니까? 아니! .. 그럴 순 없어. 암호가 약하더라도 테이블에 SSID a387csf3에 대한 해시가 없습니다. 이것이 무작위 소금의 아름다움입니다. 사전 계산 테이블에서 번성하는 크래커를 막을 것입니다. 결정된 해커를 막을 수 있습니까? 아마 아닙니다. 그러나 무작위 소금을 사용하면 추가적인 방어 층이 제공됩니다. 우리가이 주제에있는 동안 임의의 소금을 별도의 시스템에 저장하는 추가 이점에 대해 논의하겠습니다. 시나리오 # 1 : 비밀번호 해시는 시스템 X에 저장되고 해싱에 사용 된 솔트 값은 시스템 Y에 저장됩니다. 이러한 솔트 값은 추측 가능하거나 알려져 있습니다 (예 : 사용자 이름) 시나리오 # 2 : 비밀번호 해시는 시스템 X에 저장되며 솔트 값은 해싱은 시스템 Y에 저장됩니다. 이러한 솔트 값은 임의적입니다. 추측 할 수 있듯이 시스템 X가 손상된 경우 별도의 시스템 (시나리오 # 2)에서 랜덤 솔트를 사용하면 큰 이점이 있습니다. 공격자는 해시를 해독 할 수 있도록 추가 값을 추측해야합니다. 32 비트 솔트를 사용하는 경우 추측되는 각 비밀번호마다 2 ^ 32 = 4,294,967,296 (약 42 억 건)의 반복이 필요할 수 있습니다. 비밀번호 해시는 시스템 X에 저장되고 해싱에 사용 된 솔트 값은 시스템 Y에 저장됩니다. 이러한 솔트 값은 추측 가능하거나 알려져 있습니다 (예 : 사용자 이름) 시나리오 # 2 : 비밀번호 해시는 시스템 X에 저장되고 해싱에 사용 된 솔트 값은 이 염분 값은 무작위입니다. 추측 할 수 있듯이 시스템 X가 손상된 경우 별도의 시스템 (시나리오 # 2)에서 랜덤 솔트를 사용하면 큰 이점이 있습니다. 공격자는 해시를 해독 할 수 있도록 추가 값을 추측해야합니다. 32 비트 솔트를 사용하는 경우 추측되는 각 비밀번호마다 2 ^ 32 = 4,294,967,296 (약 42 억 건)의 반복이 필요할 수 있습니다. 비밀번호 해시는 시스템 X에 저장되고 해싱에 사용 된 솔트 값은 시스템 Y에 저장됩니다. 이러한 솔트 값은 추측 가능하거나 알려져 있습니다 (예 : 사용자 이름) 시나리오 # 2 : 비밀번호 해시는 시스템 X에 저장되고 해싱에 사용 된 솔트 값은 이 염분 값은 무작위입니다. 추측 할 수 있듯이 시스템 X가 손상된 경우 별도의 시스템 (시나리오 # 2)에서 랜덤 솔트를 사용하면 큰 이점이 있습니다. 공격자는 해시를 해독 할 수 있도록 추가 값을 추측해야합니다. 32 비트 솔트를 사용하는 경우 추측되는 각 비밀번호마다 2 ^ 32 = 4,294,967,296 (약 42 억 회)의 반복이 필요할 수 있습니다. 이 소금 값은 무작위입니다. 추측 할 수 있듯이 시스템 X가 손상된 경우 별도의 시스템 (시나리오 # 2)에서 랜덤 솔트를 사용하면 큰 이점이 있습니다. 공격자는 해시를 해독 할 수 있도록 추가 값을 추측해야합니다. 32 비트 솔트를 사용하는 경우 추측되는 각 비밀번호마다 2 ^ 32 = 4,294,967,296 (약 42 억 회)의 반복이 필요할 수 있습니다. 이 소금 값은 무작위입니다. 추측 할 수 있듯이 시스템 X가 손상된 경우 별도의 시스템 (시나리오 # 2)에서 랜덤 솔트를 사용하면 큰 이점이 있습니다. 공격자는 해시를 해독 할 수 있도록 추가 값을 추측해야합니다. 32 비트 솔트를 사용하는 경우 추측되는 각 비밀번호마다 2 ^ 32 = 4,294,967,296 (약 42 억 회)의 반복이 필요할 수 있습니다.

PHP 5.5에는 래퍼를 제공하는 암호 해싱 API 가 포함되어 있음을 지적하고 싶습니다 crypt(). 이 API는 암호 해시 해시, 확인 및 재해시 작업을 크게 단순화합니다. 필자는 PHP 5.3.7 이상을 사용 하는 사용자를 위해 호환성 팩 (단순 require하게 사용 하는 단일 password.php 파일 형식)을 출시했으며 지금이 기능을 사용하려고합니다.

현재는 BCRYPT 만 지원하지만 다른 암호 해싱 기술을 포함하도록 쉽게 확장되는 것을 목표로하며 기술과 비용이 해시의 일부로 저장되므로 선호하는 해싱 기술 / 비용을 변경해도 현재 해시, 프레임 워크가 무효화되지 않습니다. 자동으로 검증 할 때 올바른 기술 / 비용을 사용합니다. 또한 명시 적으로 자신을 정의하지 않은 경우 "보안"소금 생성을 처리합니다.

API는 다음과 같은 네 가지 기능을 제공합니다.

• password_get_info() -주어진 해시에 대한 정보를 반환
• password_hash() -비밀번호 해시를 만듭니다.
• password_needs_rehash()-주어진 해시가 주어진 옵션과 일치하는지 확인합니다. 해시가 현재 기술 / 비용 체계를 준수하는지 확인하여 필요한 경우 다시 해시 할 수 있습니다.
• password_verify() -비밀번호가 해시와 일치하는지 확인

현재이 함수는 PASSWORD_BCRYPT 및 PASSWORD_DEFAULT 비밀번호 상수를 허용합니다. 이는 현재 동의어입니다. PASSWORD_DEFAULT는 "새로운, 강력한 해싱 알고리즘이 지원 될 때 최신 PHP 릴리스에서 변경 될 수 있습니다." 로그인시 PASSWORD_DEFAULT 및 password_needs_rehash ()를 사용하고 (필요한 경우 다시 해싱) 해시가 거의 또는 전혀 작동하지 않는 무차별 대입 공격에 대해 합리적으로 탄력적이어야합니다.

편집 : 나는 이것이 Robert K의 대답에 간략하게 언급되어 있음을 깨달았습니다. 이 답변은 작동 방식과 보안을 모르는 사람들에게 제공하는 사용 편의성에 대해 조금 더 많은 정보를 제공한다고 생각하므로 여기에 남겨 두겠습니다.

필자 는 거의 모든 PHP 프로젝트에서 매우 쉽게 구현할 수있는 간단한 단일 파일 PHP 클래스 인 Phpass 를 사용 하고 있습니다. H 참조 .

기본적으로 Phpass에서 구현 된 가장 강력한 암호화를 사용했습니다.이 암호화는 bcryptWordpress와 같은 프레임 워크와의 호환성을 제공하기 위해 MD5까지 다른 암호화로 대체 됩니다.

반환 된 해시는 그대로 데이터베이스에 저장 될 수 있습니다. 해시 생성을위한 샘플 사용은 다음과 같습니다.

$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($password);

비밀번호를 확인하기 위해 다음을 사용할 수 있습니다.

$t_hasher = new PasswordHash(8, FALSE);
$check = $t_hasher->CheckPassword($password, $hash);

기억해야 할 것들

PHP의 비밀번호 암호화에 대해 많은 의견이 있었지만 대부분의 경우 좋은 조언이지만, 비밀번호 암호화에 PHP를 사용하기 전에 다음을 구현하거나 구현할 준비가되었는지 확인하십시오.

섬기는 사람

포트

PHP와 DB를 실행하는 서버를 제대로 보호하지 않으면 암호화 성능이 아무리 우수하더라도 모든 노력이 가치가 없습니다. 대부분의 서버는 상대적으로 동일한 방식으로 작동하며 포트는 ftp 또는 셸을 통해 원격으로 액세스 할 수 있도록 할당되어 있습니다. 원격 연결이 활성화 된 기본 포트를 변경해야합니다. 이 작업을 수행하지 않으면 침입자가 시스템에 액세스 할 때 한 단계 더 적은 작업을 수행하게됩니다.

사용자 이름

세계에서 좋은 모든 사용자 이름 admin, root 또는 이와 유사한 것을 사용하지 마십시오. 또한 유닉스 기반 시스템을 사용하는 경우 루트 계정 로그인에 액세스 할 수 없도록 설정하면 항상 sudo 만 있어야합니다.

암호

해킹 당하지 않도록 사용자에게 올바른 비밀번호를 만들도록 지시하십시오. 백도어를 넓게 열었을 때 현관 문을 잠그는 모든 노력을 기울이는 요점은 무엇입니까?

데이터 베이스

섬기는 사람

이상적으로는 DB와 APPLICATION이 별도의 서버에 있어야합니다. 비용으로 인해 항상 가능한 것은 아니지만 공격자가 시스템에 완전히 액세스하려면 두 단계를 거쳐야하기 때문에 약간의 안전이 허용됩니다.

사용자

응용 프로그램은 항상 DB에 액세스하기 위해 자신의 계정을 가지고 있어야하며 필요한 권한 만 부여하십시오.

그런 다음 응용 프로그램에서도 서버의 어느 곳에도 저장되지 않은 별도의 사용자 계정이 있어야합니다.

항상이 루트 나 비슷한 것을 만들지 마십시오.

암호

모든 올바른 비밀번호와 동일한 지침을 따르십시오. 또한 동일한 시스템의 SERVER 또는 DB 계정에서 동일한 비밀번호를 재사용하지 마십시오.

PHP

암호

절대 DB에 암호를 저장하지 말고 해시와 고유 한 소금을 저장하지 마십시오. 나중에 이유를 설명하겠습니다.

해싱

단방향 해싱 !!!!!!!, 비밀번호를 되돌릴 수있는 방식으로 비밀번호를 해시하지 마십시오. 같은 방법으로 두 해시를 비교하십시오. 즉, 침입자가 DB에 액세스하더라도 실제 암호가 무엇인지 모르고 결과 해시 만 알 수 있습니다. 이는 최악의 시나리오에서 사용자에게 더 많은 보안을 의미합니다.

거기에는 좋은 해싱 함수가 많이 있지만 ( password_hash, hash등 ...) 해시를 적용하려면 올바른 알고리즘을 선택해야합니다. (bcrypt와 비슷한 알고리즘은 괜찮은 알고리즘입니다.)

해싱 속도가 핵심 일 때는 Brute Force 공격에 대한 내성이 느려집니다.

해싱에서 가장 일반적인 실수 중 하나는 해시가 사용자에게 고유하지 않다는 것입니다. 이것은 주로 소금이 고유하게 생성되지 않기 때문입니다.

염분

비밀번호는 해시하기 전에 항상 소금에 절 여야합니다. Salting은 암호에 임의의 문자열을 추가하므로 DB에서 유사한 암호가 동일하게 표시되지 않습니다. 그러나 소금이 각 사용자에게 고유하지 않은 경우 (즉, 하드 코딩 된 소금을 사용하는 경우) 소금을 무가치하게 만든 것보다 많이 사용합니다. 일단 공격자가 하나의 암호 소금을 알아 내면 모든 암호 소금이 있습니다.

솔트를 생성 할 때 솔트가 암호에 고유한지 확인한 다음 완성 된 해시와 솔트를 모두 DB에 저장하십시오. 이것이하는 일은 공격자가 접근하기 전에 각각의 소금과 해시를 개별적으로 해독해야하는 것입니다. 이는 공격자에게 더 많은 작업과 시간을 의미합니다.

비밀번호를 만드는 사용자

사용자가 프론트 엔드를 통해 비밀번호를 작성하는 경우 서버로 비밀번호를 보내야합니다. 이것은 암호화되지 않은 암호가 서버로 전송되고 공격자가 PHP의 모든 보안을 듣고 쓸 수 없다면 보안 문제를 야기합니다. 항상 데이터를 안전하게 전송하십시오. 이것은 SSL을 통해 이루어 지지만 SSL이 완벽하지 않더라도 지칠 수 없습니다 (OpenSSL의 Heartbleed 결함이 그 예입니다).

또한 사용자가 안전한 암호를 만들도록하십시오. 간단하고 항상 수행해야하며 결국 사용자에게 감사드립니다.

마지막으로, 아무 것도 취하지 않는 보안 조치가 100 % 안전하더라도 보호 할 기술이 향상 될수록 공격이 더욱 발전합니다. 그러나이 단계를 따르면 사이트를보다 안전하고 공격자가 방문하는 것이 훨씬 바람직하지 않게됩니다.

다음은 비밀번호에 쉽게 해시와 솔트를 생성하는 PHP 클래스입니다.

http://git.io/mSJqpw

구글은 SHA256이 PHP에서 사용 가능하다고 말합니다.

반드시 소금을 사용해야합니다. 임의의 바이트를 사용하는 것이 좋습니다 (문자와 숫자로 제한하지 마십시오). 일반적으로 더 오래 선택할수록 더 안전하고 느려집니다. 64 바이트는 괜찮을 것 같습니다.

결국, 이중 해싱은 수학적으로 아무런 이점을 제공하지 않습니다. 그러나 실제로는 레인보우 테이블 기반 공격을 방지하는 데 유용합니다. 다시 말해, 애플리케이션이나 서버에서 프로세서 시간이 훨씬 단축되는 솔트를 사용한 해싱보다 더 큰 이점이 없습니다.

https://crackstation.net/hashing-security.htm 에서이 문제에 대한 완벽한 주제를 찾았 습니다. 여기서 이점을 얻고 싶었습니다. 시간 기반 공격에 대한 예방도 제공하는 소스 코드도 있습니다.

<?php
/*
 * Password hashing with PBKDF2.
 * Author: havoc AT defuse.ca
 * www: https://defuse.ca/php-pbkdf2.htm
 */

// These constants may be changed without breaking existing hashes.
define("PBKDF2_HASH_ALGORITHM", "sha256");
define("PBKDF2_ITERATIONS", 1000);
define("PBKDF2_SALT_BYTES", 24);
define("PBKDF2_HASH_BYTES", 24);

define("HASH_SECTIONS", 4);
define("HASH_ALGORITHM_INDEX", 0);
define("HASH_ITERATION_INDEX", 1);
define("HASH_SALT_INDEX", 2);
define("HASH_PBKDF2_INDEX", 3);

function create_hash($password)
{
    // format: algorithm:iterations:salt:hash
    $salt = base64_encode(mcrypt_create_iv(PBKDF2_SALT_BYTES, MCRYPT_DEV_URANDOM));
    return PBKDF2_HASH_ALGORITHM . ":" . PBKDF2_ITERATIONS . ":" .  $salt . ":" . 
        base64_encode(pbkdf2(
            PBKDF2_HASH_ALGORITHM,
            $password,
            $salt,
            PBKDF2_ITERATIONS,
            PBKDF2_HASH_BYTES,
            true
        ));
}

function validate_password($password, $good_hash)
{
    $params = explode(":", $good_hash);
    if(count($params) < HASH_SECTIONS)
       return false; 
    $pbkdf2 = base64_decode($params[HASH_PBKDF2_INDEX]);
    return slow_equals(
        $pbkdf2,
        pbkdf2(
            $params[HASH_ALGORITHM_INDEX],
            $password,
            $params[HASH_SALT_INDEX],
            (int)$params[HASH_ITERATION_INDEX],
            strlen($pbkdf2),
            true
        )
    );
}

// Compares two strings $a and $b in length-constant time.
function slow_equals($a, $b)
{
    $diff = strlen($a) ^ strlen($b);
    for($i = 0; $i < strlen($a) && $i < strlen($b); $i++)
    {
        $diff |= ord($a[$i]) ^ ord($b[$i]);
    }
    return $diff === 0; 
}

/*
 * PBKDF2 key derivation function as defined by RSA's PKCS #5: https://www.ietf.org/rfc/rfc2898.txt
 * $algorithm - The hash algorithm to use. Recommended: SHA256
 * $password - The password.
 * $salt - A salt that is unique to the password.
 * $count - Iteration count. Higher is better, but slower. Recommended: At least 1000.
 * $key_length - The length of the derived key in bytes.
 * $raw_output - If true, the key is returned in raw binary format. Hex encoded otherwise.
 * Returns: A $key_length-byte key derived from the password and salt.
 *
 * Test vectors can be found here: https://www.ietf.org/rfc/rfc6070.txt
 *
 * This implementation of PBKDF2 was originally created by https://defuse.ca
 * With improvements by http://www.variations-of-shadow.com
 */
function pbkdf2($algorithm, $password, $salt, $count, $key_length, $raw_output = false)
{
    $algorithm = strtolower($algorithm);
    if(!in_array($algorithm, hash_algos(), true))
        die('PBKDF2 ERROR: Invalid hash algorithm.');
    if($count <= 0 || $key_length <= 0)
        die('PBKDF2 ERROR: Invalid parameters.');

    $hash_length = strlen(hash($algorithm, "", true));
    $block_count = ceil($key_length / $hash_length);

    $output = "";
    for($i = 1; $i <= $block_count; $i++) {
        // $i encoded as 4 bytes, big endian.
        $last = $salt . pack("N", $i);
        // first iteration
        $last = $xorsum = hash_hmac($algorithm, $last, $password, true);
        // perform the other $count - 1 iterations
        for ($j = 1; $j < $count; $j++) {
            $xorsum ^= ($last = hash_hmac($algorithm, $last, $password, true));
        }
        $output .= $xorsum;
    }

    if($raw_output)
        return substr($output, 0, $key_length);
    else
        return bin2hex(substr($output, 0, $key_length));
}
?>

나는 보통 사용자 ID (또는 다른 사용자 특정 정보)와 함께 SHA1과 소금을 사용하고 때로는 일정한 소금을 사용하기도합니다 (따라서 소금에 2 부분이 있습니다).

SHA1은 이제 다소 손상되었지만 MD5보다 훨씬 낮은 수준으로 간주됩니다. 소금 (모든 소금)을 사용하면 해시를 공격하기 위해 일반 레인보우 테이블 을 사용하지 못하게됩니다 (일부 사람들은 해시를 검색하여 일종의 레인보우 테이블로 Google을 사용하는 경우도있었습니다). 공격자는 소금을 사용하여 무지개 테이블을 생성 할 수 있으므로 사용자 별 소금을 포함시켜야합니다. 이렇게하면 전체 시스템에 대한 것이 아니라 시스템의 모든 레코드에 대해 레인보우 테이블을 생성해야합니다! 이러한 유형의 염분을 사용하면 MD5조차도 상당히 안전합니다.

가까운 미래에는 SHA1 과 소금이 충분할 것입니다 (당연히 Fort Knox를 위해 무언가를 코딩하는지 또는 쇼핑 목록을위한 로그인 시스템에 따라). SHA1이 충분하지 않으면 SHA256을 사용하십시오 .

소금의 아이디어는 해싱 결과를 균형에서 벗어나게하는 것입니다. 예를 들어, 빈 문자열의 MD5 해시는 d41d8cd98f00b204e9800998ecf8427e입니다. 따라서 충분한 메모리를 가진 사람이 해시를보고 빈 문자열의 해시임을 알 수 있습니다. 그러나 문자열이 솔트 된 경우 (예 : 문자열 " MY_PERSONAL_SALT")는 '빈 문자열'(예 : " MY_PERSONAL_SALT") 의 해시 가 aeac2612626724592271634fb14d3ea6되므로 역 추적에는 명확하지 않습니다. 내가 말하려는 것은 소금 을 사용 하지 않는 것보다 낫다는 것입니다. 그러므로 어떤 소금을 사용 해야하는지 아는 것은 그리 중요하지 않습니다 .

실제로이 작업을 수행하는 웹 사이트가 있습니다-(md5) 해시를 제공 할 수 있으며 해당 해시를 생성하는 알려진 평문을 뱉어냅니다. 일반 md5 해시를 저장하는 데이터베이스에 액세스하는 경우 관리자가 해당 서비스에 대한 해시를 입력하고 로그인하는 것이 쉽지 않을 것입니다. 그러나 암호가 소금에 절인 경우 이러한 서비스는 효과적인.

또한 이중 해싱은 일반적으로 결과 공간이 줄어들 기 때문에 잘못된 방법으로 간주됩니다. 모든 인기있는 해시는 고정 길이입니다. 따라서이 고정 길이의 유한 값만 가질 수 있으며 결과의 편차가 줄어 듭니다. 이것은 다른 형태의 소금으로 간주 될 수 있지만 권장하지는 않습니다.

맞습니다. 소금 소금이 필요합니다. 소금 소금은 독특해야합니다.

   /**
     * Generating string
     * @param $size
     * @return string
     */
    function Uniwur_string($size){
        $text = md5(uniqid(rand(), TRUE));
        RETURN substr($text, 0, $size);
    }

또한 우리는 sha512를 사용하는 해시가 필요합니다. 최고이며 PHP입니다.

   /**
     * Hashing string
     * @param $string
     * @return string
     */
    function hash($string){
        return hash('sha512', $string);
    }

이제이 기능을 사용하여 안전한 비밀번호를 생성 할 수 있습니다.

// generating unique password
$password = Uniwur_string(20); // or you can add manual password
// generating 32 character salt
$salt = Uniwur_string(32);
// now we can manipulate this informations

// hashin salt for safe
$hash_salt = hash($salt);
// hashing password
$hash_psw = hash($password.$hash_salt);

이제 $ hash_psw 변수 값과 $ salt 변수를 데이터베이스에 저장해야합니다

승인을 위해 동일한 단계를 사용합니다.

고객 비밀번호를 보호하는 가장 좋은 방법입니다 ...

마지막 2 단계의 PS는 자신의 알고리즘을 사용할 수 있지만 나중에 사용자에게 권한을 부여해야 할 때이 해시 암호를 생성 할 수 있는지 확인하십시오 ...