레거시 시스템을 API로 연동하다 보면 로그인이라는 첫 관문에서 예상치 못한 벽을 만납니다. 요청을 캡처해서 열어 봤는데 아이디와 비밀번호 자리에 사람이 읽을 수 없는 문자열이 들어 있는 경우입니다. 평문이 아니라 클라이언트 안에서 한 번 암호화된 값이 서버로 갑니다. 한 통행료 정산 시스템이 그랬습니다. 이 값을 그대로 흉내 낼 수 없다면 프로그램은 로그인 자체를 통과할 수 없습니다. 이 글은 그 암호화된 로그인을 어떻게 해석하고 재현했는지를 정리한 것입니다.
왜 자격증명이 암호화되어 오는가
오래된 사내 시스템 중에는 자격증명을 서버로 보내기 전에 클라이언트 쪽에서 한 번 암호화하는 방식이 드물지 않습니다. 통신 구간 자체가 암호화되지 않던 시절의 관행이거나, 화면단에서 최소한의 보호를 하려는 설계의 흔적입니다. 이유가 무엇이든 연동하는 입장에서는 사실 하나가 분명해집니다. 서버가 받아들이는 것은 원래의 비밀번호가 아니라 그 암호화된 결과물이므로, 프로그램도 같은 방식으로 자격증명을 암호화해서 보내야 합니다.
여기서 관점을 분명히 할 필요가 있습니다. 이 작업은 시스템을 뚫거나 우회하는 것이 아닙니다. 정당하게 발급받은 계정으로 로그인할 때, 그 계정이 원래 거치는 암호화 절차를 프로그램이 똑같이 재현하는 것뿐입니다. 사람이 화면에서 로그인할 때 자동으로 일어나던 일을, 화면 없이 프로그램이 대신 수행하는 것이라고 이해하면 정확합니다. 목표는 시스템을 속이는 것이 아니라, 시스템이 이미 정해 둔 규칙에 맞춰 정직하게 대화하는 것입니다.
캡처값과 입력을 대조해 방식을 좁히다
암호화를 재현하려면 먼저 어떤 방식인지 알아야 합니다. 단서는 캡처된 요청 안에 있었습니다. 현장에서 실제 로그인을 할 때 어떤 아이디와 비밀번호를 넣었는지 알고 있고 그때 서버로 전송된 암호문도 캡처에 남아 있습니다. 즉 원래 입력과 그 결과가 한 쌍으로 확보된 상태였습니다. 이 한 쌍이 있으면, 여러 후보 방식을 하나씩 시험해 같은 입력에서 같은 결과가 나오는 방식을 찾아낼 수 있습니다.
암호문의 길이와 문자 구성에서도 힌트가 나왔습니다. 결과가 특정 인코딩으로 감싸인 고정된 블록 단위의 형태였는데, 이는 널리 쓰이는 대칭키 블록 암호의 특징과 맞아떨어졌습니다. 후보를 그쪽으로 좁히고 짧은 입력값 하나를 같은 방식으로 암호화했을 때 캡처된 암호문과 정확히 일치하는지 확인했습니다. 한 글자도 다르지 않게 같은 결과가 나오는 순간, 방식과 그에 딸린 세부 규칙이 확정됩니다. 이 대조 검증이 있으면 추측이 사실로 바뀝니다.
패딩과 인코딩이라는 마지막 디테일
암호화 방식을 알아도 세부 규칙이 어긋나면 결과가 달라집니다. 특히 두 가지가 결정적이었습니다. 하나는 패딩입니다. 블록 암호는 입력을 정해진 블록 크기의 배수로 맞춰야 하는데, 남는 자리를 어떤 값으로 채우느냐에 따라 결과가 완전히 달라집니다. 이 시스템은 빈자리를 특정 방식으로 채우고 있었고 입력이 이미 블록 크기의 배수일 때는 아예 채우지 않는 등 미세한 규칙이 있었습니다. 다른 하나는 인코딩입니다. 암호화된 바이트를 사람이 다룰 수 있는 문자열로 바꾸는 방식까지 캡처와 맞춰야 최종 결과가 일치했습니다.
이 디테일들을 캡처값으로 하나하나 검증하며 맞추자, 임의의 아이디와 비밀번호를 넣어도 서버가 받아들이는 로그인 요청을 프로그램이 스스로 만들 수 있게 됐습니다. 검증은 방향을 바꿔서도 해 봤습니다. 프로그램이 만든 암호문을 다시 원래 값으로 되돌려 입력과 같은지 확인하는 왕복 검증입니다. 다만 이런 방식에는 후행 처리에서 데이터가 조용히 손상될 수 있는 함정도 있어 자격증명처럼 안전이 확인된 범위에서만 되돌림을 쓰도록 사용 범위를 분명히 제한했습니다.
키는 코드에 남기지 않는다
암호화를 재현하려면 키와 초기값이 필요합니다. 이 값들은 자격증명에 준하는 민감 정보이므로 소스 코드에 절대 하드코딩하지 않았습니다. 대신 외부 설정으로 주입해 프로그램 코드에는 암호화의 절차만 있고 실제 키 값은 설정 파일에만 존재하도록 분리했습니다. 마찬가지로 아이디와 비밀번호도 코드가 아니라 별도의 비밀 설정에서 읽어 옵니다. 이렇게 하면 코드가 유출되어도 자격증명과 키가 함께 새지 않고 값을 교체할 때도 코드를 건드릴 필요가 없습니다.
로그인이라는 첫 관문을 이렇게 통과하고 나면, 그다음은 각 동작에 맞는 요청을 만드는 일이 이어집니다. 그런데 이 시스템은 로그인 다음에도 요청 형식이 조금만 어긋나면 처리를 거부하는 까다로움이 있었습니다. 그 이야기는 바이트 단위 요청 재현으로 오류 잡기에서 다룹니다. 이 로그인 해석을 포함한 시스템 전체가 어떻게 실제 업무 자동화로 이어졌는지는 레거시 통행료 시스템 역설계 연동 사례에 정리했습니다.
자주 묻는 질문
암호화된 로그인을 재현하는 건 해킹 아닌가요?
아닙니다. 정당하게 발급받은 계정으로, 그 계정이 원래 거치는 암호화 절차를 화면 없이 프로그램이 똑같이 수행하는 것입니다. 사람이 로그인할 때 자동으로 일어나던 일을 대신하는 것이며 시스템의 보안을 깨거나 우회하는 것이 아니라 시스템이 정한 규칙을 그대로 따르는 것입니다.
어떻게 암호화 방식을 알아냈나요?
현장에서 실제 로그인을 하며 원래 입력값과 그때 전송된 암호문을 한 쌍으로 확보했습니다. 이 한 쌍이 있으면 여러 후보 방식을 시험해 같은 입력에서 같은 결과가 나오는 방식을 특정할 수 있습니다. 암호문의 길이와 형태도 방식을 좁히는 단서가 됩니다.
키가 유출될 위험은 없나요?
키와 초기값, 아이디와 비밀번호는 모두 소스 코드에 넣지 않고 외부 설정으로 주입합니다. 코드에는 암호화 절차만 있고 실제 값은 설정에만 존재하므로, 코드가 노출되어도 민감 정보가 함께 새지 않습니다. 값을 교체할 때도 설정만 바꾸면 됩니다.