v2
★ MILESTONE · BOARD

원시적인 회원가입/로그인

의도적으로 위험한 첫 버전

학습 목표

  • 의도적으로 「위험한 인증」 을 만들어본다
  • 평문 비밀번호 / 무상태 의 문제를 직접 체감한다
  • v3 에서 무엇을 고칠지 명확히 본다

⚠️ 왜 일부러 위험하게?

학습 전략 — 「불편 먼저, 도구 나중」

v3 에서 BCrypt + 세션을 도입할 때 — 그 도구가 「왜 좋은지」 가 머리에 박히려면, 도구 없는 상태의 답답함을 직접 겪어봐야 합니다.

v2 는 일부러 위험. v3 가 그 위험을 푸는 모습을 다음 차시에서.

🛠️ v2 의 두 가지 의도된 위험

평문 + 무상태
  • ① 평문 비밀번호 — 입력 그대로 DB 에 저장
  • ② 무상태 로그인 — 로그인 성공해도 세션 저장 안 함 → 페이지 옮기면 풀림

v2 의 테이블 — 최소 두 컬럼


CREATE TABLE mymember (
    id  VARCHAR(50)  PRIMARY KEY,
    pwd VARCHAR(20)  NOT NULL
);

👉 pwd VARCHAR(20) — 평문 비밀번호엔 충분. 하지만 v3 에서 BCrypt 도입 시 이 길이가 문제.

회원가입 — 평문 그대로


package com.smhrd.service;

@Service
public class MemberService {
    @Autowired private MemberMapper mapper;

    // ⚠️ 평문 그대로 저장 (의도적 위험)
    public void signup(Member m) {
        mapper.insert(m);  // pwd 변환 없이 그대로
    }
}


-- DB 의 결과
SELECT id, pwd FROM mymember;

id      | pwd
--------+----------
hong    | mypw1234     ← 평문 그대로!
kim     | secret999

왜 평문이 위험한가

시나리오
  • DB 가 어떤 이유로든 유출되면 — 모든 사용자의 비밀번호 노출
  • 관리자도 사용자 비밀번호를 그대로 봄 → 신뢰 문제
  • 사용자들이 같은 비밀번호를 다른 사이트에도 쓰는 경우 → 다른 서비스도 위험
  • 법적 책임 — 개인정보보호법 위반 가능성

👉 v3 에서 BCrypt 단방향 해시로 해결.

로그인 — 비교만


public Member login(String id, String pwd) {
    Member m = mapper.selectOne(id);
    if (m != null && m.getPwd().equals(pwd)) {
        return m;       // 단순 문자열 비교
    }
    return null;
}

👉 BCrypt 같은 해시 비교 X. 단순 String.equals().

로그인 처리 — 세션 저장 X


@PostMapping("/login")
public String login(@RequestParam String id,
                     @RequestParam String pwd) {
    Member m = service.login(id, pwd);
    if (m == null) {
        return "redirect:/login?error";
    }
    return "redirect:/";
    // ⚠️ session.setAttribute 안 함!
}
결과

로그인은 성공하지만 — 다른 페이지로 이동하면 「누구였는지」 모름. 모든 페이지가 비로그인 상태.

실험 — 직접 체감

  1. v2 코드로 회원가입
  2. DB 직접 SELECT — 비밀번호가 평문으로 보임 ⚠️
  3. 로그인 성공
  4. 메인 페이지 이동 — 「로그인 안 한 상태」 처럼 보임
  5. 「로그인이 안 유지되네...?」 직접 느껴봄
  6. 왜 그런지를 안 채로 v3 로 진행 → 해결책의 의미가 살아남

v2 의 의미

v2 는 학습용 일회성 단계입니다. 실제 서비스에선 절대 사용 X.

  • v2 의 목적 = 「불편 체험」
  • v3 에서 BCrypt + 세션으로 고침
  • 두 줄·세 줄의 변경이 보안을 어떻게 바꾸는지 비교

🔄 Before / After

전 차시 끝

회원가입 폼은 만들었지만 인증 흐름 전체는 미완성.

→
v2 끝

위험한 인증이 작동한다. 두 가지 문제 (평문 / 무상태) 를 직접 체감.

정리

오늘 들고 가는 것

  • v2 = 의도적으로 위험한 인증
  • ① 평문 저장 ② 세션 없는 로그인 = 두 가지 문제
  • 다음 차시 v3 에서 두 문제 모두 해결
  • 실 서비스에선 절대 사용 X

다음: 쿠키 깊이 보기 → 세션 깊이 보기 → ★ v3 안전 인증.