Hacker News 의견들
  • Signal의 암호화된 전화번호 조회 시스템이 흥미로움
    서버가 하드웨어 암호화된 RAM에서 비트 단위 XOR 연산을 사용해 번호를 조회하기 때문에, 시스템을 가장 낮은 수준에서 들여다봐도 요청한 전화번호가 존재하는지 여부를 알 수 없음
    물론 rate limiting은 별도의 중요한 문제임. 보안 시스템을 만들 때는 커버해야 할 엣지 케이스가 정말 많음

    • 이런 방식이 멋지다고 생각하지 않음. 애초에 보안 메신저라면 개인 식별자인 전화번호를 요구하지 않아야 함
    • 정부가 모든 전화번호에 대한 조회 요청을 보내면 Signal이 이를 막을 수 있는지 궁금함
      Matrix 같은 비상업적·프라이버시 중심 플랫폼에서는 이런 매핑 자체를 불가능하게 해야 함
      예를 들어, 사용자가 자신의 연락처 목록에 있는 사람만 자신을 찾을 수 있도록, 각 사용자 쌍의 전화번호를 해시한 값을 업로드하는 방식 제안
      장점은 해시 공간이 넓어 역추적이 어렵고, 사용자가 발견 허용 범위를 직접 정할 수 있음
      단점은 공격자가 모든 번호 조합을 생성해 연락처 관계를 추출할 수 있고, 정부는 SMS 인증을 가로채 이를 악용할 수도 있음
    • 서버가 하드웨어 암호화된 RAM에서 XOR을 사용한다는 부분이 흥미로움. 이에 대한 추가 자료가 있는지 궁금함
    • 여전히 전화번호를 요구하는 게 아쉬움. 최근에야 username 기능이 추가되어 번호 노출을 피할 수 있게 되었지만, 여전히 SIM 기반 계정이라는 점이 꺼림칙함
    • 하지만 우리가 직접 Signal 서버를 빌드해 운영할 수 없으니, 실제로 서버가 이런 처리를 하는지 확신할 수 없음
  • 사용자 객체의 pin 필드가 의심스러움
    아마도 opt-out 직렬화 라이브러리를 써서 생긴 문제일 가능성이 있음. 기본적으로 객체 전체를 직렬화하기 때문에, 개발자가 특정 필드를 제외하는 설정을 깜빡하면 그대로 노출됨
    혹은 서버에서 단순히 JS 딕셔너리를 쓰다가 응답 전 필드를 제거하지 않았을 수도 있음
    이 취약점은 비엔나 대학 연구팀 논문에서 언급된 오래된 문제로, 2016년 Telegram에서도 동일한 방식으로 악용되어 이란 정부가 1,500만 명의 사용자 전화번호를 수집했음
    관련 링크: Telegram 블로그

    • 예전 직장에서 코드 감사를 하며 이런 직렬화 취약점을 곳곳에서 발견했음. 개발자들은 이런 라이브러리를 이제 그만 써야 함
    • 이런 문제는 정말 흔함. 민감한 필드가 클라이언트로 전송되는데, UI에서는 보이지 않으니 아무도 눈치채지 못함
    • PIN이 노출된 것도 문제지만, 평문 저장이라는 점이 더 심각함. 비밀번호처럼 강력한 해시 알고리즘으로 처리했어야 함
  • 요즘 보안 취약점의 대부분은 단순히 예상치 못한 방식으로 HTTP 엔드포인트를 호출하는 것에서 비롯됨
    2025년에 해킹이라 하면 복잡한 기술을 떠올리지만, 실제로는 rate limiting조차 없는 API를 배포하는 게 현실임. Nginx 설정 한 줄이면 해결될 문제임

    • “Nginx 설정 한 줄이면 된다”는 말에 대해, “그게 Docker 튜토리얼에 없어서 뭔지 모른다”는 식의 반응이 떠오름
    • 소프트웨어 개발은 발전했지만, 보안 개발 원칙은 거의 성장하지 못했음
      대부분의 목표는 사용자 마찰을 줄이고 상업적 효율성을 높이는 것임. 많은 개발자들이 XSS나 SSRF 같은 기본적인 취약점을 모른 채 기능만 구현함
    • 단순한 설정이라도 존재 자체를 알아야 적용할 수 있음
    • 예전엔 자동화된 내부 보안 스캔이 쓸모없다고 생각했지만, 실제로 기본적인 설정을 빠뜨리는 사례를 보고 나서는 필수라고 느낌
      Docker 포트 매핑 실수나 CSP 누락 같은 기초적인 보안 실수가 너무 흔함
    • 하지만 rate limiting만으로는 충분하지 않음. 공격자는 IP를 분산시켜 병렬 요청을 보낼 수 있음
  • “최고의 블로그 글만 독자들에게 제공하고 싶다”는 문장을 보고, 글쓴이와 유사한 성향의 사람을 찾은 기분이 들었음

  • Freedom Chat®이 기자가 그룹 채팅에 참여하지 못하게 하는 기능이 있는지 궁금함. 농담 반 진담 반으로 DoD 친구를 위해 묻는 중임

  • 올해만 해도 “보안 앱”이 사용자 데이터를 다루다 유출한 사례가 여러 번 있었음
    기억나는 것만 해도 20센트어치(=4건) 정도지만, 아마 더 많을 것 같음
    관련 사례: 1, 2, 3

    • 이번 사건을 계기로 Facebook Messenger 외부로 나가는 움직임이 중요하다고 생각함
    • 그리고 우리가 아는 건 그중 일부일 뿐임
  • 작년에 GOP 구직 게시판을 우연히 봤는데, 지원서가 구인 공고와 같은 검색 인덱스에 저장되어 있었음
    “bob”이라고 검색하니 지원자들의 이력서와 답변이 그대로 노출되어 충격이었음

    • 어떤 사이트였는지 궁금함
  • Anom 사건 이후로는 “honeypot”보다 더 적절한 단어가 필요함
    진짜 안전한 메신저는 이런 방식으로는 나오지 않을 것임. 하지만 마케팅은 계속되고, 매번 새로운 사용자들이 끌려들어옴

    • 요즘은 실패가 곧 기능이 되는 세상
      데이터 유출이 너무 자주 일어나서 이제는 사람들도 무감각해짐. 집단소송 보상도 결국 개인정보를 더 제공하는 과정이 되어버림
      예측시장, 암호화폐 등도 결국 참여자에게 손해를 주는 구조적 실패를 ‘성공’처럼 포장하는 느낌임
    • “Petepot”이라는 새 단어 제안이 나옴
  • Freedom Chat이 “문제 수정 완료”라고 공지했지만, 정말 수정된 건지 의문

  • “모바일 앱 개발 경험은 없지만, 똑똑하니까 어렵지 않을 거라 생각했다”는 문장이 실제 인용이라면, 거의 스탠드업 코미디 대사처럼 들림