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