Password 감사
문제
독일어 원문
Nennen Sie zwei Folgen der Passwortspeicherung in der Tabelle und wie man sie verbessern kann.
한국어 해석
표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?
실제 시험에 제시된 Login 코드·사용자 표
index.html
1 <form action="http://api.example.com/login.php" method="GET">
2 Username: <input type="text" id="user" name="user">
3 Password: <input type="password" id="pw" name="pw">
4 <input type="submit" value="Login">
5 </form>users
| login | password | role | |
|---|---|---|---|
| admin | king2026 | administrator | bob.king@example.com |
| alice | wonderland2002 | user | alice303@gmail.com |
| bob | king2026 | user | bob.king@gmail.com |
| charlie | 123456 | guest | ch.ar.lie.xxx@gmail.com |
| eve | 34@s5wa-rPg5.5 | readonly | eve.online.1997@gmail.com |
login.php
2 $user = $_GET['user'];
3 $pass = $_GET['pw'];
4 $sql = "SELECT * FROM users WHERE login = '$user' AND password = '$pass'";
5 $result = $conn->query($sql);
6 if ($result->num_rows > 0) {
7 echo "<div>Erfolgreich angemeldet!</div>";
8 } else {
9 echo "<div>Fehlgeschlagener Login für Nutzer: " . $user . "</div>";
10 }출처: 실제 시험지 p13–14. 각 소문제에서 같은 code/data flow를 다시 추적합니다.
Password 비교 실습
비밀번호를 눌러 공격자 관점의 이유를 확인하세요.
단계별 힌트
막혔을 때만 한 단계씩 여세요. 정답을 바로 읽는 것보다 기억을 꺼내는 시간이 중요합니다.
- 첫 힌트: 비밀번호를 금고에 넣는 대신 명단 옆에 그대로 적어 둔 상태다. 필요한 것은 복호화 가능한 암호문이 아니라 login 때 다시 계산해 비교할 verifier다.
- 즉시 계정 탈취를 쓴다.
- password reuse/credential stuffing 확산을 쓴다.
- unique salt+slow password hash/KDF를 쓴다.
- 함정: 빠른 SHA-256 한 번만으로 충분하다고 쓰지 않는다.
- 함정: 비밀번호를 encryption해서 복호화 가능하게 저장하는 것을 최선이라 하지 않는다.
- 후속 점검: salt와 pepper의 역할 차이는?
채점 기준으로 내 답안 점검하기
- 즉시 계정 탈취를 쓴다.
- password reuse/credential stuffing 확산을 쓴다.
- unique salt+slow password hash/KDF를 쓴다.
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/3 slots
정답과 핵심 해설 확인하기
평문 저장이라 DB 유출 즉시 모든 비밀번호가 노출되고, 재사용한 다른 서비스까지 credential stuffing 피해가 번진다. 사용자별 salt가 포함된 느린 password KDF를 사용한다. PHP에서는 `password_hash`의 Argon2id/bcrypt 결과를 `password_verify`로 검사하며, scrypt는 검증된 별도 library/API가 필요하다.
- 즉시 계정 탈취를 쓴다.
- password reuse/credential stuffing 확산을 쓴다.
- unique salt+slow password hash/KDF를 쓴다.
개념부터 다시 보는 상세 풀이
BEGINNER LESSON
웹 보안: 이 문제를 처음부터 이해하기
ZERO-BASE START
정말 아무것도 모른다고 가정하고 시작합니다
전문 용어를 알고 있다고 가정하지 않습니다. 먼저 일상적인 장면을 보고, 그 장면의 사람과 행동에 실제 보안 용어를 하나씩 붙인 뒤, 시스템에서 일어나는 순서를 따라갑니다.
기초 개념 01
Password를 저장하지 않고 검증값을 저장하는 법
1타 강사식 시작: 이름은 잠시 가리고 장면부터 봅시다
비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
지금은 이 비유를 완벽히 외울 필요가 없습니다. 누가 무엇을 가지고 있고, 무엇을 하려 하며, 어느 지점에서 문제가 생기는지만 찾으면 됩니다.
이제 실제 용어를 하나씩 붙여 봅시다
Server는 사용자의 plaintext password를 다시 읽을 필요가 없다. 가입할 때 각 사용자마다 무작위 salt를 만들고 password와 함께 느린 password KDF에 넣어 나온 hash와 salt만 저장한다. 로그인 때 입력 password로 같은 계산을 수행해 비교한다. Argon2id, bcrypt, scrypt, PBKDF2 같은 KDF는 반복 계산과 memory 사용으로 대량 추측을 비싸게 만든다.
TERMS FROM ZERO
전문 용어를 한 단어씩 풀기
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Password hash / KDF
Password 검증을 위해 의도적으로 비용을 높여 만든 단방향 계산 결과입니다.
Salt
사용자마다 새로 만드는 공개 random 값으로 같은 password도 서로 다른 저장 결과를 만들게 합니다.
Cost parameter
Password 추측 한 번에 필요한 시간·memory 비용을 조절하는 설정입니다.
Offline guessing
공격자가 유출된 database를 자기 장비에서 server 제한 없이 시험하는 공격입니다.
프로그램이나 프로토콜 안에서는 다음 순서로 움직입니다.
- 사용자마다 고유한 random salt를 생성한다.
- Password와 salt를 느린 KDF에 넣는다.
- Salt, KDF parameter, 결과 hash를 저장한다.
- 로그인 시 검증 API로 비교하고 role authorization은 별도로 확인한다.
왜 여기서 많이 틀릴까요?
일반적인 빠른 hash 한 번만 사용하거나 모든 사용자에게 같은 salt를 쓰면 대량 추측과 미리 계산한 table 공격에 약하다.
조건을 생략하거나 서로 다른 기능을 같은 것으로 취급했는지 확인하세요. 정답 문장을 외우는 것보다 틀린 이유를 말할 수 있어야 변형 문제를 풀 수 있습니다.
핵심부터 말하면 비밀번호를 금고에 넣는 대신 명단 옆에 그대로 적어 둔 상태다. 필요한 것은 복호화 가능한 암호문이 아니라 login 때 다시 계산해 비교할 verifier다.
이 글에서 익힐 것
표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?
이 문항에 연결된 1개 기초 개념과 4개 전문 용어를 자신의 말로 설명한다.
정의만 외우지 않고 구체적인 입력·message·code 흐름을 단계별로 재현한다.
시험 답안에서 결론과 근거, 조건 또는 한계를 함께 쓴다.
이 문제가 어려운 이유
문제 문장은 짧지만 초보자가 이미 안다고 가정하는 용어와 중간 단계가 숨어 있습니다. 이 페이지에서는 ‘표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?’를 바로 외우지 않고, 아래 연결 개념을 일상 장면에서 시작해 실제 시스템 순서로 바꿉니다.
문제가 묻는 것
표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?
문제가 요구하는 동사와 답의 개수를 먼저 표시하고, 등장 주체·입력·처리 순서·보안 효과·남는 한계를 차례로 적습니다.
먼저 알아야 할 개념
-
Password를 저장하지 않고 검증값을 저장하는 법
Server는 사용자의 plaintext password를 다시 읽을 필요가 없다. 가입할 때 각 사용자마다 무작위 salt를 만들고 password와 함께 느린 password KDF에 넣어 나온 hash와 salt만 저장한다. 로그인 때 입력 password로 같은 계산을 수행해 비교한다. Argon2id, bcrypt, scrypt, PBKDF2 같은 KDF는 반복 계산과 memory 사용으로 대량 추측을 비싸게 만든다.
비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
예제로 확인하기
-
Password를 저장하지 않고 검증값을 저장하는 법을 이 문제에 대입하기
비밀번호 원본을 창고에 보관하는 대신, 입력한 열쇠가 맞는지만 검사하는 느린 시험 장치를 보관하는 것이다. Salt는 같은 열쇠라도 사용자마다 다른 시험지를 받게 한다.
사용자마다 고유한 random salt를 생성한다.
Password와 salt를 느린 KDF에 넣는다.
Salt, KDF parameter, 결과 hash를 저장한다.
로그인 시 검증 API로 비교하고 role authorization은 별도로 확인한다.
위 순서를 문제 문장 ‘표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?’에 적용하면, 이 문항의 핵심 결론은 평문 저장이라 DB 유출 즉시 모든 비밀번호가 노출되고, 재사용한 다른 서비스까지 credential stuffing 피해가 번진다. 사용자별 salt가 포함된 느린 password KDF를 사용한다. PHP에서는 `password_hash`의 Argon2id/bcrypt 결과를 `password_verify`로 검사하며, scrypt는 검증된 별도 library/API가 필요하다.입니다.
정답까지 사고 과정
즉시 계정 탈취를 쓴다.
password reuse/credential stuffing 확산을 쓴다.
unique salt+slow password hash/KDF를 쓴다.
시험장에서는 이렇게 쓰기
핵심 해설
평문 저장이라 DB 유출 즉시 모든 비밀번호가 노출되고, 재사용한 다른 서비스까지 credential stuffing 피해가 번진다. 사용자별 salt가 포함된 느린 password KDF를 사용한다. PHP에서는 `password_hash`의 Argon2id/bcrypt 결과를 `password_verify`로 검사하며, scrypt는 검증된 별도 library/API가 필요하다.
시험 답안으로 정리하기
즉시 계정 탈취를 쓴다.
password reuse/credential stuffing 확산을 쓴다.
unique salt+slow password hash/KDF를 쓴다.
자주 틀리는 지점
빠른 SHA-256 한 번만으로 충분하다고 쓰지 않는다.
비밀번호를 encryption해서 복호화 가능하게 저장하는 것을 최선이라 하지 않는다.
채점 포인트
즉시 계정 탈취를 쓴다.
password reuse/credential stuffing 확산을 쓴다.
unique salt+slow password hash/KDF를 쓴다.
한 줄로 기억하기
비밀번호를 금고에 넣는 대신 명단 옆에 그대로 적어 둔 상태다. 필요한 것은 복호화 가능한 암호문이 아니라 login 때 다시 계산해 비교할 verifier다.
스스로 확인하기
salt와 pepper의 역할 차이는?
AI 구두시험용 프롬프트
한 문항만 풀어라. 먼저 정답을 열지 말고 90초 안에 답안을 말한 뒤, css-ws2025-26-web-php-005의 채점 프레임으로 스스로 채점하라. 문제: 표의 password 저장 방식이 만드는 결과 두 가지와 개선책은?
학습 기록