서버는 1대 클라이언트는 N명
서버와 N명의 클라이언트가 서로 비밀 구절(고정된 문자열K)를 가지고 있다.
이때 클라이언트가 API에 K 문자열을 보내면 패킷이 외부에 노출되기 때문에
K를 단방향 해시함수로 암호화하여 서버에서 전송하고
서버에서는 해시 문자열 간 일치 여부를 판단하기로 한다.
전제조건 1) HTTPS가 아닌 HTTP 통신으로 패킷 암호화가 안된다.
전제조건 2) 주어진 단방향 해시함수 알고리즘을 변경할 수 없다.
하지만, 문자열K를 해시 암호화한 "고정된 문자열"로도
항상 서버에 요청 권한을 얻을 수 있는 문제가 있다.
이에 대한 문제를 해결하거나 최소화할 방법을 제안하세요.
정답은 GPT에게 질문하면 나옴
서버도 문자열 K, 클라도 문자열 K 인건가
ㅇㅇ통신하기전에 서로 K값은 가지고 있음 다만 해커가 패킷 청취가 문제 - dc App
문제가 살짝 이해가 안가서 해시 암호화한 "고정된 문자열"로도 서버에 요청 권한을 얻을 수 있는 문제가 있다. 이게 무슨 소리야??
아무나 서버에 요청 권한을 얻을 수 있는게 문제라는거야??
K를 암호화한게 A이면 서버에서는 A==A를 비교하고 A값은 해커가 볼 수 있음 - dc App
문자열 K가 고정이니까 요청에 K를 보내던 H(K)를 보내던 어차피 똑같다는거임 K가 같으면 H(K)도 같으니까
아 이해함
jwt 토큰 탈취랑 비슷한 문제임 - dc App
나는 사용자마다 password의 길이를 hash할때 salt로 주고 요청을 보낼거같음 서버는 그 사용자의 비밀번호의 길이를 아니까 ㅇㅇ 그걸로 해시하고 서버에서 체킹하면 안됨? 이것도 완전무결한 방법은 아닌데 흠
대칭키방식의 수동https인가
이게 답이면 말도안되지 전제조건이 https불가랑 해시 알고리즘 변경 불가인데
정해진 답은 없음 그냥 말만 되면됨 - dc App
완전히 해결못해도 좋으니 최소화할 방안을 생각해보셈 - dc App
일회용 공개키/비밀키 사용?
서버가 공개키 개인키 갖고 공개키 뿌리는 그거 아님?
어렵당..
전제조건에 대칭키를 쓰지 말라잖아
세션 방식처럼 k문자열과 현재 시간 (날짜-시 까지)을 함께 해시 암호화한 문자열을 서버로 보내고, 서버는 똑같이 서버와 현재시간을 암호화한 해시 문자열을 비교한다. 이때 운이 정말 나쁜 정상 유저가 요청에 실패할 수 있기 때문에 이전 시간 기준으로 생성된 문자열도 같이 비교해서 일치하는게 있으면 요청을 허용한다. 조금 생각해서 썼는데 이거 맞나?
아 ‘서버는 똑같이 서버와 현재시간을’ -> ‘서버는 똑같이 k문자열과 현재 시간을’으로 바꿔야 함
정답임 타임스탬프에서 분까지만 자르고 K랑 결합해서 암호화하고 서버에서는 5분이라고 치면 -5 -4 -3 -2 -1 0분까지 비교해서 한개라도 일치하면 검증통과 - dc App
써놓고 보니까 세션방식이랑 비슷하지도 않네 저 말도 취소
물론 다른 방식도 있겠지만 내가 생각한 방식은 이거임 - dc App
굳
jwt키 하나만 쓸 때 문제랑 비슷한데 보통 salt나 난수 추가하는 등 사전 약속된 식별자 추가하거나 유효시간 짧게 해서 탈취해도 못 쓰게 하거나 둘이 조합하거나 아님?
맞음 타임스탬프 결합 - dc App
타임스탬프로 분-초 단위로 자른 문자열 붙여서 처리하거나, 클라가 자기가 몇번째 클라이언트인지 알면 그거 붙이거나.. 일단 분까지만 자른 뒤 유효기간 플마 1분으로 하고 유효기간 1분으로 하면 위험성 많이 줄일 수는 있을듯?
Csrf 하듯이 세션마다 nonce 넘겨주기 아니면 사용된 nonce 목록을 관리하기
좋다 - dc App
근데최초연결이문제네
아니다 연결할때 H(k+nonce), nonce 넘기면 ,K값 아는놈만 수락할수있군
암복호화 원리를 묻는거네 걍 salt 추가?