Passwords Intro & Plain text Problem

rang-dev·2020년 3월 19일
0

Passwords Intro

Passwords are ubiquitous and the ABSOLUTE worst.

보통 우리는 비밀번호를 사용해서 authentication을 하는데 사용자들은 비밀번호를 안전하게 사용하는 것을 알지 못한다. 또한 개발자들은 비밀번호를 충분히 심각하게 생각하지 않기 때문에 간단한 것을 놓치며 공격의 위험에 우리의 시스템을 노출시키기 때문에, 비밀번호를 사용하는 것은 최악의 방법이다.

기본 인증 시스템을 살펴보자. 위험은 전체 stack에 걸쳐서 존재한다.

  1. Frontend: Our user don't take passwords seriously.
    Frontend내에서, 우리는 두개의 주요 위험을 가진다. 하나는 사용자가 암호를 사용하고 저장하는 방식이며 다른 하나는 코드 관점에서 시스템을 관리하고 유지 관리하는 방법이다.
    우리는 password를 저장할 장소가 필요하다. 보통 우리는 database 안에 정보를 저장한다. 하지만 만약 발생하기 쉬운 실수라도 한다면 우리의 데이터베이스는 위험에 노출된다. 어떤 malicious player는 우리의 시스템을 부수고 말그대로 table에 저장되어 있는 passwords를 읽을 수 있다.

  2. Database
    만약 database가 위험에 노출되어있지 않다면, API를 통해서 database로 접근할 수도 있다. 여기서, 개발자들은 일치하는 것처럼 보이는 두 개의 암호를 확인하는데 필요한 검사를 실제로 수행하는 시스템을 구축하고 있으며, 중요한 정보를 기록(logging)하거나 추적하지 않을 추가 책임을 가지고 있다.
    Frontend에서 API server로, API server에서 database로 전송되는 데이터들 또한 위험에 노출되어 있다. 만약 그러한 tranasmissions이 제대로 포맷되지 않았다면 그들은 서비스간을 이동(en-route)하는 동안 쉽게 가로채어질 수 있다. 이 경우, 그것들은 마치 단순한 텍스트인 것처럼 읽힐 수 있다. 궁극적으로 책임은 우리 개발자들에게 달려있다.

이번 레슨에서 나쁜 사람들이 시스템을 파괴해온 방법을 이해하면서 패스워드에 적대적인 접근을 할 것이다. 또한 이러한 공격들을 완화시킬 방법들을 배울 것이다.

Problem with Plain Text

처음 Authentication dasign을 할때 plain text로 password를 저장하고 새로 입력된 password와 맞는지 확인하는 방법은 쉽고 간단하지만 최악의 방법이다.

우리는 database에 관련된 위험에 집중하여 살펴볼 것이다.

특히 비밀번호를 plain text로 저장하는 것이 얼마나 최악인지 말이다.

Our Database is Vulnerable

Table에 string으로 저장된 username과 password 짝은 위험하다. 왜냐면 이 정보들은 영원한 비밀이 보장되지 않기 때문이다. 보장되는 것이 우리의 최종 목표지만 우리는 아마 실수를 할 것이다.

Database내에 있는 데이터를 잘못되게 하는 많은 방법들이 있다.
1. Bad Actor within our organization
정보를 훔치려는 사람
2. Bad Database Passwords
만약 너무 쉬운 관리자 비밀번호를 사용하거나 비밀번호가 노출되었다면 전체 시스템이 노출된 것이다.
3. Bad Backup Security
백업을 충분히 안전하게 하지 않는 경우이다. 만약 매달 3박스의 정보를 폐기한다면 버려지는 정보에 대한 보안은 신경쓰지 않는다. 백업되는 정보는 우리가 데이터베이스 안에 가지고 있는 정보만큼 중요하다.
4. SQL Injection
시스템의 다른 부분에서 데이터베이스 내의 데이터에 액세스 할 위험이 있다.

Our API Server is Vulnerable

  1. Bad Actors
    특정 정보를 흘리는 코드를 사람이 조직 내에 있을 수도 있다.
  2. Bad Logging
    또한 개발자들은 패스워드를 포함한 특정 유저 데이터를 로깅하는 실수를 할 수도 있다. 또한 그들은 로그를 심각하게 취급하지 않는 경향이 있다.
  3. Bad ORM/Serializers
    우연히 모델 전체를 가져 와서 비밀번호를 프론트 엔드로 직접 발송한다.

Our In Flight Data in Vulnerable

Plain text passwords는 전송되는(in flight) 데이터를 굉장한 위험에 노출시킨다. 예를들어 백엔드 서버로 전달되는 프론트 엔드 요청은 호텔 Wi-Fi를 통하며, 데이터베이스로 연결되는 API server는 네트워크의 로컬 컴퓨터에 있다. 실제 위험이 있다고 생각하지 않으므로 그들을 동일한 Wi-Fi에 연결한다.

하지만 이러한 연결이 암호화 된 신호를 통해 발생하지 않으면 해당 plaintext 비밀번호를 가로채 일반 텍스트로 읽을 수 있다. 이것은 모두 plain text로 정보를 보내거나 저장해서 발생하는 문제이다. 따라서 우리는 plain text를 대체하는 더 안전한 방법들을 찾아볼 것이다.

User Table Vulnerability: SQL Injection


ORM을 사용하여 데이터베이스에 대한 인터페이스를 추상화 할 수 있다. 하지만 이것은 문제를 완전히 해결하지는 않는다.

profile
지금 있는 곳에서, 내가 가진 것으로, 할 수 있는 일을 하기 🐢

0개의 댓글