서비스의 암호 데이터베이스가 누출 될 때마다 걱정해야하는 이유
"우리 암호 데이터베이스는 어제 도난당했습니다. 그러나 암호는 암호화되어 있습니다. "우리는 어제 나 야후를 비롯하여 온라인과 같은 진술을 정기적으로 볼 수 있습니다. 그러나 우리는이 보증을 액면 그대로 받아 들여야합니다.?
현실은 암호 데이터베이스 손상입니다. 아르 아무리 회사가 그것을 회전 시키려고해도 상관 없습니다. 그러나 회사의 보안 관행이 얼마나 나쁜지 상관없이 자신을 보호하기 위해 할 수있는 몇 가지 방법이 있습니다..
암호 저장 방법
이상적인 세상에서 회사가 암호를 저장하는 방법은 다음과 같습니다. 계정을 만들고 암호를 제공합니다. 암호 자체를 저장하는 대신 서비스는 암호에서 "해시"를 생성합니다. 이것은 뒤집을 수없는 독특한 지문입니다. 예를 들어, 암호 "password"는 "4jfh75to4sud7gh93247g ..."과 비슷한 것으로 바뀔 수 있습니다. 로그인 할 때 암호를 입력하면 서비스는 해시를 생성하고 해시 값이 데이터베이스에 저장된 값과 일치하는지 확인합니다. 어떤 시점에서든 서비스는 암호 자체를 디스크에 저장하지 않습니다..
실제 암호를 판별하려면 데이터베이스에 액세스 할 수있는 공격자가 공통 암호에 대한 해시를 미리 계산 한 다음 데이터베이스에 암호가 존재하는지 확인해야합니다. 공격자는 룩업 테이블 (암호와 일치하는 해시 목록)을 통해이를 수행합니다. 그런 다음 해시를 데이터베이스와 비교할 수 있습니다. 예를 들어 공격자는 "password1"에 대한 해시를 알고 데이터베이스의 계정 중 해시가 사용 중인지 확인합니다. 암호가 맞다면 공격자는 자신의 암호가 "password1".
이를 방지하기 위해 서비스는 해시를 "소금"처리해야합니다. 암호 자체에서 해시를 만드는 대신 암호 해시를하기 전에 임의의 문자열을 암호 앞이나 끝에 추가합니다. 다시 말해서 사용자가 암호 "password"를 입력하면 서비스가 salt를 추가하고 "password35s2dg"와 비슷한 암호를 해시합니다. 각 사용자 계정에는 고유 한 소금이 있어야하며 이렇게하면 각 사용자 계정 데이터베이스에서 암호에 대해 다른 해시 값을가집니다. 여러 계정이 암호 "password1"을 사용하더라도 소금 값이 다르기 때문에 해시가 다릅니다. 이는 암호 해시를 사전 계산하려고 시도한 공격자를 물리 칠 수 있습니다. 한 번에 전체 데이터베이스의 모든 사용자 계정에 적용된 해시를 생성 할 수있는 대신, 각 사용자 계정 및 고유 한 소금에 대해 고유 한 해시를 생성해야합니다. 이것은 훨씬 더 많은 계산 시간과 메모리를 필요로 할 것입니다..
이것이 서비스가 종종 걱정하지 않는다고 말하는 이유입니다. 적절한 보안 절차를 사용하는 서비스는 소금에 절인 암호 해시를 사용하고 있다고 말해야합니다. 단순히 패스워드가 "해시되었다"고 말하면 더 걱정이됩니다. LinkedIn은 암호를 해시했지만 (예를 들어 암호를 해독하지 않았습니다.) LinkedIn에서 2012 년 650 만 건의 해시 암호를 잃어 버렸을 때 큰 문제였습니다..
잘못된 비밀번호 관행
이것은 구현하기가 가장 힘든 일이 아니지만 많은 웹 사이트는 여전히 다양한 방식으로 망가 뜨리고 있습니다.
- 암호를 일반 텍스트로 저장: 해싱에 신경을 쓰는 대신 최악의 범죄자 중 일부는 일반 텍스트 형식의 암호를 데이터베이스에 덤프 할 수 있습니다. 이러한 데이터베이스가 유출 된 경우 암호가 분명히 손상됩니다. 그들이 얼마나 강한 지 상관 없습니다..
- 암호없이 해싱하기: 일부 서비스는 암호를 해시하고 소금을 사용하지 않기로 결정할 수 있습니다. 이러한 암호 데이터베이스는 조회 테이블에 매우 취약합니다. 공격자는 많은 암호에 대해 해시를 생성 한 다음 데이터베이스에 존재하는지 확인합니다. 소금을 사용하지 않으면 모든 계정에 대해이를 한 번에 수행 할 수 있습니다.
- 소금 재사용: 일부 서비스는 소금을 사용할 수도 있지만 모든 사용자 계정 암호에 대해 동일한 소금을 재사용 할 수 있습니다. 이것은 무의미합니다. 동일한 소금이 모든 사용자에 대해 사용 된 경우 동일한 암호를 사용하는 두 명의 사용자가 동일한 해시를가집니다..
- 짧은 소금 사용: 단 몇 자릿수의 소금을 사용하는 경우 모든 가능한 소금을 포함하는 찾아보기 테이블을 생성 할 수 있습니다. 예를 들어, 한 자릿수가 소금으로 사용 된 경우 공격자는 가능한 모든 소금을 포함하는 해시 목록을 쉽게 생성 할 수 있습니다.
회사는 항상 전체 이야기를 말할 수는 없으므로 패스워드가 해쉬 (또는 해시되고 소금에 절인)라고해도 최상의 방법을 사용하지 않을 수 있습니다. 항상주의의 측면에서 잘못했다..
기타 우려 사항
salt 값이 암호 데이터베이스에도 존재할 가능성이 있습니다. 이는 각 사용자별로 고유 한 소금 값이 사용 되었다면 공격자는 엄청난 양의 CPU 전력을 사용하여 모든 암호를 파괴해야합니다..
실제로 많은 사람들이 분명한 암호를 사용하기 때문에 많은 사용자 계정 암호를 쉽게 판단 할 수 있습니다. 예를 들어 해커가 해시를 알고 있고 소금을 알고 있다면 가장 일반적인 암호를 사용하고 있는지 쉽게 확인할 수 있습니다.
공격자가 암호를 알아내어 암호를 해독하기를 원하는 경우 소금 값을 알고있는 한 무차별 대용 암호를 사용하여 공격 할 수 있습니다. 암호 데이터베이스에 대한 로컬 오프라인 액세스를 통해 공격자는 원하는 모든 무차별 대입 공격을 사용할 수 있습니다..
암호 데이터베이스를 도난 당하면 다른 개인 데이터도 누출 될 수 있습니다. 사용자 이름, 전자 메일 주소 등. 야후 유출의 경우 보안 질문과 답변도 누출되었습니다. 우리 모두 알다시피 다른 사람의 계정에 대한 액세스를 도용하기 쉽습니다..
도움, 무엇을해야합니까??
암호 데이터베이스가 도난 당했을 때 어떤 서비스가 언급 되더라도 모든 서비스가 완전히 무능하다고 생각하고 그에 따라 행동한다고 가정하는 것이 가장 좋습니다.
먼저 여러 웹 사이트에서 비밀번호를 다시 사용하지 마십시오. 각 웹 사이트마다 고유 한 암호를 생성하는 암호 관리자를 사용하십시오. 공격자가 서비스의 암호가 "43 ^ tSd % 7uho2 # 3"이라는 것을 발견하고 그 특정 웹 사이트에서만 해당 암호를 사용하면 아무 것도 유용하지 않다는 것을 배웠습니다. 어디에서나 동일한 암호를 사용하면 다른 계정에 액세스 할 수 있습니다. 이것은 얼마나 많은 사람들의 계정이 "해킹 당하는가"입니다.
서비스가 해킹 당하면 사용중인 암호를 변경하십시오. 다른 사이트에서 암호를 재사용하는 경우에도 암호를 변경해야합니다. 그러나 처음에는 암호를 사용해서는 안됩니다..
공격자가 암호를 알아 낸 경우에도 보호 할 수있는 이중 인증 사용을 고려해야합니다..
가장 중요한 것은 암호를 다시 사용하지 않는 것입니다. 손상된 비밀번호 데이터베이스는 신용 카드 번호와 같이 데이터베이스에 중요한 정보를 저장하지 않는 한 어디에서나 고유 한 비밀번호를 사용하면 해를 끼치 지 않습니다..
이미지 크레딧 : Marc Falardeau on Flickr, 위키 미디어 공용
