회사에서 비밀번호를 암호화하지 않은 경우 수행 할 작업

배경

회사에서 서버를 유지 관리하도록 계약을 체결했습니다. 나는 몇 가지 사소한 PHP 프로젝트를 수행하지만 성능 문제를 검토하고 최근에는 해커의 로그를 스캔합니다.

이 사람들은 얼마 동안 서버를 운영하고 있으며 마지막 레그에서 레거시 애플리케이션이라고 부르는 것을 가지고 있습니다. 마법 따옴표, 전역 변수 ( $id로 덮어 쓸 수 있음 $_GET['id'])를 사용하고 .htaccess를 유일한 보안으로 사용하는 경우가 있습니다. 보안 및 프로그래밍 악몽.

우리는 과거에 SLEEP(99999999)명령 을 실행 하고 DOS 공격의 역할을하는 SQL 인젝션으로 해킹당했습니다 . 다행히 그들은 "작은 바비 테이블"을 실행하지 않았습니다.

XKCD : http://xkcd.com/327/

그래서 나는 mysql_query()mysqli가 아닌 취약한 SQL 문 을 PDO 트랜잭션에 다시 썼다 . 그리고 우리가 사용하지 않지만 주사에 대한 SLEEP및에 대한 쿼리를 분석하고 UNION있습니다. 여태까지는 그런대로 잘됐다.

최신호

최근 우리는 전자 메일 주소와 같은 사용자의 전자 메일 주소가 아마도 스패머가 만든 것으로 레코드가 DB에서 변경되고 있다고 들었습니다.

열에 열이없는 것을 알았 last_modified으므로 누가 변경했는지는 알 수 없었습니다. 그 칼럼을 추가했지만 첫 단계는 아닙니다.

이 표를 살펴볼 때 비밀번호가 소금에 절이거나 해시되지 않고 평문으로 저장되는 것을 알았습니다.

고객 커뮤니케이션

매드 맨처럼 팔을 찢지 않고 계약자로서 전체 상황에 대해 어떻게 접근 할 수 있습니까? 어떤 충고? 나는 차분한 접근을 생각하고 있었다.

    문제 # 1
        개요
        이것이 왜 문제인가
        이것이 해결되지 않으면 어떻게됩니까?
        제안 된 수정

    문제 # 2
        개요
        이것이 왜 문제인가
        이것이 해결되지 않으면 어떻게됩니까?
        제안 된 수정
        

당신이 제안하는 침착 한 접근법이 가장 좋을 것입니다. 이 데이터가 노출되면 대부분의 사용자는 비밀번호 재사용으로 인해 신원 도용에 취약 할 수 있음을 지적합니다. 이것은 회사가 목표가 아니라고 가정 할 때 이것이 목표에 영향을 준 것과 동일한 문제라는 것을 지적하기에 꽤 좋은시기입니다. 그리고 당신의 매니저는 이것을 바꾸는 것을 꽤 수용해야합니다.

데이터의 적법성과 관련하여 사용자 이름 / 암호가 CC 데이터, 개인 정보 등과 같은 것으로 간주되지는 않습니다. 사용자에 대한 정보가 무엇인지에 따라 달라질 수 있습니다. 나는 변호사가 아니므로 이러한 측면은 당신의 계시에서 가장 잘 드러날 것이며 합법성을 결정하기 위해 회사의 법무 부서로 가져와야합니다.

https://ko.wikipedia.org/wiki/Information_privacy_law

그리고 당신은 당신을 돕기 위해이 XKCD를 가지고 있습니다 :

그것은 실제로 당신이 이것으로 접근하려는 청중에 달려 있습니다. 나는 당신과 같은 심각한 보안 문제가있는 회사에서 일했지만 아직 그들에게 그것을 보여줄 때까지 듣기를 거부했습니다.

가능한 경우, 한 가지 접근 방식은 기본적으로 이러한 해킹에서 발생했을 수있는 항목을 항목별로 분류하려는 의도대로 수행하려는 작업을 조합하는 것입니다. 잠재 고객이 기술이 아닌 경우 이러한 타협으로 인해 발생할 수있는 비즈니스 비용을 지적해야합니다. 분명히 해킹 된 계정은 시스템의 신뢰성과 제품의 고객 가치를 인식하지 못하게합니다. 사용자를 위해 일반 텍스트 암호와 전자 메일 주소가있는 손상된 시스템은 말할 것도없고 심각한 파급 효과를 초래할 수 있습니다.

가능하다면 다음에해야 할 일은 그것을 증명하는 것입니다. 테스트 환경에서이 시스템을 세워 놓을 수 있다면 그렇게하십시오. 그런 다음 응용 프로그램의 클라이언트 쪽에서 시스템에 미칠 수있는 영향에 대해 설명하십시오. 기술 사람들조차도 이것은 나를 위해 설득력이있는 것으로 판명되었습니다 (그러나 그들은 여전히 ​​내 경우에는 행동하지 않습니다).

물론, 당신이 말했듯이 어떤 조치를 취해야하는지 설명하고 그것을 달성하기위한 노력에 대한 추정이 필요합니다. 일부 장소는 단순히 신경 쓰지 않지만 비용을 정당화하는 데 도움이됩니다. 적어도 당신은 당신의 의식을 지우고 당신이 시도한 것을 알고 앞으로 나아갈 수 있습니다.

서버 유지 관리 계약을 체결했다면 운영 체제, 응용 프로그램 소프트웨어 및 모든 데이터의 무결성, 보안 및 가용성 보장과 같은 작업 설명 작업에 반드시이 계약이 포함되어야합니까? 계약이 서버의 보안을 보장하기 위해 기대하고 책임을진다는 모호한 힌트조차도 비즈니스 사례를 정리하는 데 시간을 낭비하지 않고 문제가 해결되도록하는 데 좋은 일을합니다. 코드 변경 사항의 버전 기록을 유지하기 전후의 백업).

나는 이와 같은 변화가 아침보다 더 많은 일을 할 것으로 기대하지 않으며 그들이 당신이 일한 시간을 물어 보면 일기를 유지하여 행동을 설명하고 정당화 할 수 있습니다. 계약 범위 내에서 작업하는 경우 여기에 문제가 없어야합니다. 때때로 의사 결정자 앞에서 모든 보안을 미치게하면 공황 상태가되거나 최악의 경우 문제를 신경 쓰지 않는다고 말할 수있는 기회가되므로 해결하지 마십시오. 위반! 어쩌면 이것이 가장 비즈니스 친화적 인 접근 방법은 아니지만 내 직업 윤리는 내가 관심을 가져야 할 책임이있는 모든 시스템에 암호화되지 않은 암호를 남겨 두는 것을 허용하지 않을 것입니다.

개인적인 경험을 통해 새로운 고용 주나 고객을 위해 일을 시작할 때마다 찾아내는 경향이 있습니다. 매번 당신에게 오지 않고이 작업을 완료하고 위반 / 사고가 의심되는 경우에만 알리겠습니다. 그들은 보안이나 컴퓨터에 대해 걱정하지 않기 때문에 거의 항상 그렇다고 대답 할 것입니다. 이것이 그들이 당신을 고용 한 이유입니다! 아마도 이것은 당신이 기대했던 방식으로 질문에 대답하지 않지만 생각을위한 음식을 제공하기를 바랍니다. 최선을 다하고 문제가 해결되기를 바랍니다!

고객의 이메일 주소 변경이 이미 발생하고 있으며 이것이 문제로 간주되는 경우 암호를 변경하는 기능도 문제입니다.

이제 향후에 이러한 일이 발생하지 않도록 DB를 충분히 확보 한 경우 누구나 사용자의 비밀번호를 편집 할 수있는 가능성이 비슷하게 수정되었으며 이제 누군가가 비밀번호를 읽을 수 있는지 여부 만 고려해야합니다.

물론 DB를 완전히 보호하지 않은 경우 (또는 가능성 이 없는 경우) 암호를 반드시 암호화해야합니다. 어떻게해야합니까? "이메일 주소 업데이트"문제와 동일한 컨텍스트에 넣으십시오. 응용 프로그램을 변경해야하는지 여부와 "너무 어려운"문제인지 여부는 응용 프로그램과 함께 제기해야하는 또 다른 문제입니다. 코드를보고 제안 된 수정을 수행하기 전에 코드 변경 비용을 확인하십시오.