News Feed

사용자 입장에서 생각하라…웹사이트 인증 프로세스 구현 원칙

컨텐츠 정보

  • 조회 752

본문

모든 웹사이트는 개인 사용자에게 맞춤화되어야 한다. 즉 사용자를 인증하고 로그인을 허용해야 한다. 전체 프로세스를 가능한 한 원활하고 안전하게 만드는 것이 소프트웨어 개발자의 일이다.

물론, 이렇게 하면 온갖 종류의 문제와 문제가 발생한다. 물론, 사용자의 데이터를 보호해야 하고, 사용자가 좋은 암호를 만들도록 유도해야 하며, 사용자가 암호를 잊어버릴 것이며 일반적으로 안전하지 않을 것이라고 가정해야 한다.

암호화와 마찬가지로 인증도 직접 개발하고 싶은 유혹을 받지만 절대 그렇게 해서는 안 된다. 업계가 충분히 발전했기 때문에 인증 솔루션을 “구축하지 말고 구입하라”라는 말을 꼭 기억해야 한다. 많은 업체가 구현하기 쉬운 솔루션을 제공하고 최신 보안 문제에 대해 부지런히 노력하고 있다.

인증은 보안과 좋은 사용자 경험 사이에서 절충안을 찾는 문제가 되기도 한다. 대부분의 서드파티 솔루션은 다양한 옵션과 기능을 제공하기 때문에, 고객과 내부 보안 담당자를 만족시킬 수 있는 좋은 선택을 하는 것은 개발자의 몫이다.

웹사이트 솔루션을 만들 때 이 모든 것을 적절하게 균형 있게 조정하는 방법에 대한 조언을 정리해 보았다.

웹사이트에서 인증을 구현할 때 주의할 점

패스키

패스키는 비교적 새로운 기술이라서 그만큼 확인되지 않은 소문도 많다. 결론적으로, 패스키는 안전하고 사용자에게 편리하다. 패스키는 사용자의 주요 인증 수단이 되어야 한다. 여러 업체에서 애플리케이션에 웹 구성 요소를 삽입하는 것보다 훨씬 쉽게 패스키를 구현하고 있다.

기기에서 공개/개인 키 암호화와 생체 인식 스캐너를 활용하는 패스키는 사용자가 선호하는 훌륭한 솔루션이다. 휴대폰에서 얼굴이나 엄지손가락을 스캔하는 것보다 암호를 입력하는 것을 선호하는 사람이 있을까? 당연히 없을 것이다. 인정하라 – 사람들은 보안이 철저하고, 복잡하고, 입력하기 어려운 암호를 입력하는 것보다 페이스 ID를 통해 은행 앱에 액세스하는 것을 선호한다.

오오스(OAuth)

패스키가 사용자를 인증하는 유일한 수단이 될 수 있지만, 일부 사용자는 좀 더 전통적인 로그인 방법을 선호할 수도 있다. 패스키를 사용하게 되면, 오오스(OAuth) 인증을 구현해야 한다. 오오스는 “구글로 로그인” 또는 “애플로 가입”하는 버튼을 통해 가장 일반적으로 이루어진다. 사용자도 오오스를 선호한다. 비밀번호를 입력하거나 계정을 만들 필요 없이 사이트에 로그인할 수 있기 때문이다. 구글, 애플, 페이스북, 마이크로소프트, 깃허브 등 인기 있는 사이트에서 로그인 서비스를 제공할 수 있다. 이 시스템 중 하나에 계정이 없는 사용자는 거의 없을 것이다.

매직 링크

또 다른 로그인 방법은 “매직 링크”를 사용하는 것이다. 매직 링크는 사용자에게 전송되는 링크로, 보통 이메일이나 문자를 통해 전송되며, 사용자는 링크를 클릭하는 것만으로 사이트에 로그인할 수 있다. 이 링크는 사용자만 볼 수 있고, 제한된 시간 동안만 유효하다는 점에서 편리하다. 단점은 사용자가 이메일을 확인하기 위해 사이트를 떠나야 한다는 점이지만, 링크를 클릭하면 바로 사이트로 돌아올 수 있다는 장점이 있다.

개발자라면 이미 알고 있겠지만, 이 추천 솔루션은 사용자가 사이트에 계정을 만들거나 암호를 기억하거나 사용자에 대한 정보를 저장할 필요가 없다. 사용자에 대한 정보를 전혀 알지 못해도 안전하고 사용자 친화적인 인증을 제공할 수 있다.

멀티팩터 인증

그러나 사용자가 시스템에 계정을 만들 수 있도록 허용해야 할 필요가 있다면, 멀티팩터 인증(MFA)을 사용해야 한다. 오늘날과 같은 시대에 사용자가 비밀번호만으로 로그인할 수 있는 기능은 단순히 문제를 불러일으킬 뿐이다.

MFA를 사용할 때는 다음 순서로 작업을 수행하는 것이 좋다.

  1. 사용자가 일회용 비밀번호(OTP)를 생성하는 애플리케이션을 사용하게 하라. 중간에서 가로챌 위험이 있는 수단으로 OTP를 전송하지 않기 때문에 가장 안전한 방법이다. 또한, 비밀번호 관리자가 OTP 제공자 역할을 할 수 있으므로 전체 과정을 자동화할 수 있다. 최종 사용자에게 가장 쉬운 솔루션이다.
  2. OTP를 이메일로 보내라. 이메일은 문자 메시지보다 가로채기가 어렵기 때문에 더 안전하다.
  3. 마지막으로, 예상치 못한 이유로 위의 두 가지 방법 중 하나를 사용할 수 없는 경우, 사용자에게 OTP를 문자로 보내라. 그러나 솔직히 말해서, 가능하면 이 방법을 피하는 것이 좋다. 문자 메시지는 안전하지 않으며, 해커가 쉽게 위조할 수 있다.

사용자가 자신의 비밀번호를 볼 수 있도록 하라

사용자가 자신의 비밀번호를 공개할 수 있는 옵션을 항상 제공해야 한다. 사용자가 입력한 내용을 확인해야 할 때가 있는데, 그렇게 할 수 없다면 짜증이 날 것이다. 물론 기본적으로 비밀번호를 가려야 하지만, 사용자가 원할 경우 공개할 수 있도록 해야 한다.

지금까지 인증 구현 시 해야 할 일에 대해 논의했다. 이제 인증에서 절대 해서는 안 되는 작업을 알아보자.

인증 구현 시 주의해야 할 사항

사용자 비밀번호를 저장하지 마라

이 말은 굳이 할 필요가 없을 것이다. 어떤 상황에서도 사용자의 비밀번호를 데이터베이스에 저장해서는 안 된다. 절대로. 대신, 비밀번호의 “솔트(salt) 및 해시(hash)” 버전을 저장하고 매번 그 값을 비교하라. 사용자가 비밀번호를 잊어버렸을 때는 새로운 비밀번호를 만들 수 있도록 하라. 사용자가 비밀번호를 잊어버렸을 때 그 비밀번호를 이메일로 보내주는 것은 “내 웹사이트가 해킹당하기 쉽다는 것을 알리는 것”과 다름없다.

복잡한 비밀번호를 요구하지 말자

직관적이지 않은 방법이라고 생각하는 사람이 많지만, 사실은 훨씬 더 안전하고 사용자 친화적이다. 사용자가 사이트에서 비밀번호를 사용해 자신의 계정을 만들 수 있도록 허용하려면, 문자, 숫자, 대소문자, 특수 문자 등에 대해 까다로운 비밀번호 요구 사항을 설정하지 마라. 대신, 최소 12자 이상의 비밀번호를 설정하라.

사용자가 기억하기 어려운 암호를 사용하도록 강요하면 암호를 적어두거나 요구 사항을 충족하는 간단한 암호를 사용할 가능성이 높아진다. 다시 말하지만, 직관적이지 않은 것처럼 보이더라도, 그렇지 않다. 또한, 암호가 길수록 해독하기가 더 어렵다.

사용자가 기억하기 쉬운 긴 암호를 만들도록 하라. 기억하기 어려운 짧은 암호를 사용하도록 강요하지 말자.

6자리보다 긴 일회용 비밀번호를 사용하지 마라

6자리가 OTP 링크의 최대 길이이고, 더 짧은 길이를 고려해야 한다. 어떤 경우에도 6자리보다 긴 OTP를 요구해서는 안 된다. 6자리보다 긴 OTP는 사용자가 단기 기억에 저장하기가 훨씬 더 어렵기 때문이다.

특수 질문을 사용하지 마라

어떤 경우에도 이 보안 기능을 사용하지 마라. 좋아하는 영화나 제 첫 번째 반려동물의 이름을 입력한 횟수는 셀 수 없을 정도이다. 그런데 “아니, 대체 무슨 소리야? 카사블랑카는 당신이 좋아하는 영화가 아니야. 그리고 당신의 첫 번째 반려동물은 럭키가 아니야”라는 말을 듣게 된다. 그 대답이 정확하다는 것을 잘 알고 있는데도 말이다. 더 나쁜 것은 소셜 미디어나 다른 수단을 통해 매우 쉽게 피싱될 수 있는 질문이라는 것이다. 이 기능을 사용하지 말자.

로그인 시도 횟수를 제한하지 말자

사용자의 로그인 시도 횟수가 몇 번 안 되는 경우, 해당 사용자의 계정을 잠그지 말자. 이렇게 하면 사용자를 짜증 나게 할 뿐이다. 어떤 날은 손가락이 굼뜰 수도 있고, 기억하기는 쉬워도 입력하기는 어려운 비밀번호가 있을 수도 있다. 그리고 사용자 계정을 “동결”하지 말자. 고객 서비스 티켓이 되면 사용자뿐만 아니라 개발자에게도 큰 불편을 초래한다.

사용자에게 암호 변경을 강요하지 말자

임의의 기간이 지난 후에 사용자에게 암호를 강제로 변경하게 강요하는 것은 보안 강화에 전혀 도움이 되지 않는다. 단지 사용자가 이전 암호의 맨끝에 숫자 하나를 추가하게 만들 뿐이다.

인증은 매우 중요하며 절대 잘못이 있어서는 안 된다. 사용 가능한 솔루션을 고려할 때, 복잡하고 사용하기 불편한 로그인이나 안전하지 않은 시스템에 대한 변명은 통하지 않는다. 그러므로 너무 복잡하게 만들지 마라. 패스키와 오오스를 사용해 암호를 요구하지 말고, 사용자를 좌절하게 하고 보안을 손상시키는 구식 관행을 버리자. 지금 같은 시대에 안전하고 구현하기 쉬우며 사용자 친화적인 인증 솔루션을 찾는 것은 결코 어렵지 않다.
dl-itworldkorea@foundryco.com

관련자료

댓글 0
등록된 댓글이 없습니다.
Member Rank