태그 보관물: passwords

passwords

REST API 호출에 비밀번호 넣기 연결을 통해 작동한다고 가정합시다. 이 암호를 호출

암호를 설정 / 재설정하는 데 사용되는 REST API가 있다고 가정하십시오. 이것이 HTTPS 연결을 통해 작동한다고 가정합시다. 이 암호를 호출 경로에 넣지 말아야 할 충분한 이유가 있습니까? 또한 BASE64로 암호화한다고 가정 해 봅시다.

예를 들어 다음과 같이 비밀번호를 재설정합니다.

http://www.example.com/user/joe/resetpassword/OLDPASSWD/NEWPASSWD

BASE64는 암호화가 아니라는 것을 알고 있지만이 경우에는 숄더 서핑의 비밀번호 만 보호하려고합니다.

답변

좋은 서버는 URL (종종 ‘?’뒤에 변수 부분이 없음), 소스 IP, 실행 시간을 포함하여 전송 된 모든 요청을 기록합니다.이 로그 (광범위한 관리자 그룹에서 잠재적으로 읽음)를 포함 하시겠습니까? 비밀번호로 정보를 안전하게 보호 하시겠습니까? Base64는 그들에 대한 스토퍼가 아닙니다.

답변

당신이 제안하는 것은 안전하거나 RESTful하지 않습니다.

@Netch는 이미 로그 관련 문제에 대해 언급했지만 HTTP로 전송 된 비밀번호를 표시한다는 점에서 또 다른 문제가 있습니다.

REST를 사용하여 GET 요청을 수행하면 URL의 다른 요소가보다 세분화 된 요소를 나타냅니다. URL은 재설정 암호의 일부인 OLDPASSWD의 NEWPASSWD 부분을 반환하는 것처럼 읽습니다. 그것은 의미 상 의미가 없습니다. GET을 사용하여 데이터를 저장해서는 안됩니다.

당신은 이런 식으로해야합니다 :

POST https://www.example.com/user/joe/resetpassword/
{oldpasswd:[data], newpasswd:[data]}

데이터를 작성하고 있기 때문에 POST, 스니핑을 원하지 않기 때문에 https.

(이것은 실제로 보안 수준이 낮습니다. 절대적으로해야합니다.)

답변

제안 된 제도는 여러 분야에서 문제가있다.

보안

URL 경로는 자주 기록됩니다. 해싱되지 않은 암호를 경로에 넣는 것은 좋지 않습니다.

HTTP

인증 / 권한 정보가 Authorization 헤더에 나타납니다. 또는 잠재적으로 브라우저 기반의 경우 쿠키 헤더입니다.

휴식

resetpasswordURL 과 같은 동사 는 일반적으로 비 표현 상태 이전 패러다임의 명확한 신호입니다. URL은 리소스를 나타내야합니다. GET 무엇을 의미 resetpassword합니까? 아니면 삭제?

API

이 체계에는 항상 이전 비밀번호를 알아야합니다. 더 많은 경우를 허용 할 것입니다. 예를 들어 비밀번호가 손실됩니다.

잘 알려진 체계 인 기본 또는 다이제스트 인증을 사용할 수 있습니다 .

PUT /user/joe/password HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Content-Type: text/plain
Host: www.example.com

NEWPASSWD

경로에 매우 민감한 정보를 넣지 않으며 HTTP 및 REST 규칙을 따릅니다.

다른 인증 모드 (예 : 확인 된 채널을 통해 비밀번호를 재설정하기 위해 전송 된 일부 토큰)를 허용해야하는 경우 다른 사항을 변경하지 않고도 다른 인증 헤더를 사용할 수 있습니다.

답변

보안 외에도이 문제는 매우 RESTful 한 접근 방식이 아니라는 것입니다.

OLDPASSWD 과 NEWPASSWD 자원 계층 구조에서 아무것도, 심지어 악화 서 있지 않는 작업이 멱등하지 않습니다.

따라서 POST동사 로만 사용할 수 있으며 리소스 경로에 두 개의 비밀번호를 포함해서는 안됩니다.

답변

문제는 요청에서 일반 텍스트 비밀번호를 사용하지 않는 것입니다. 편안한 웹 서비스 요구 사항을 충족시키는 두 가지 옵션이 있습니다.

1. 클라이언트 측 해싱

  • 예를 들어 hash (password + salt)와 같은 비밀번호를 저장하고 있다고 생각합니다.
  • 클라이언트 측에서 소금으로 새 비밀번호를 해시 할 수 있습니다.
  • 즉, 클라이언트 측에 새 솔트를 만들고 해시를 만듭니다 (예 : hash (newPassword + newSalt)).
  • 새로 생성 된 해시와 소금을 편안한 웹 서비스로 보냅니다.
  • 이전 비밀번호를 hash (oldPassword + oldSalt)로도 전송

2. 암호화

  • / otk / john과 같은 사용자를위한 “일회성 키”(otk) 리소스를 만듭니다.
  • 이 리소스는 안전한 임의의 고유 한 일회용 키를 반환합니다.
  • 당신의 편안한 웹 서비스는 ID 95648915125와의 다음 안전한 통신을 위해이 임의의 otk를 저장해야합니다
  • otk를 사용하여 새 비밀번호와 기존 비밀번호를 암호화하십시오 (예 : AES) 보안상의 이유로 이전 비밀번호와 새 비밀번호에 대해 두 개의 별도 otks를 사용해야합니다.
  • ID가 95648915125 인 비밀번호 변경 자원으로 암호화 된 비밀번호를 전송하십시오.
  • 하나의 otk 및 ID 조합은 한 번만 작동 할 수 있으므로 비밀번호를 변경 한 후 해당 조합을 삭제해야합니다.
  • 더 나은 옵션 : Basic-Auth로 현재 / 이전 암호를 보냅니다.

참고 : 두 옵션 모두 HTTPS가 필요합니다!

답변

비밀번호 재설정 작업의 기능은 무엇입니까?

  1. 뭔가 바뀝니다.
  2. 설정된 값이 있습니다.
  3. 일부 사용자 만 수행 할 수 있습니다 (사용자, 관리자 또는 둘 중 하나에 대한 다른 규칙이있을 수 있음).

여기서 1 포인트는 GET을 사용할 수 없음을 의미합니다. 비밀번호 변경 작업을 나타내는 자원을 비밀번호 변경을 처리하는 자원을 나타내는 URI에 POST하거나 새 비밀번호를 나타내는 무언가를 비밀번호를 나타내는 URI에 PUT 또는 무언가를 나타내는 것 (예 : 해당 비밀번호가 기능인 사용자).

일반적으로 POST는 어색 할 수 있기 때문에 나중에 게시 할 수 없습니다. 나중에 GET 할 수없고 암호를 얻을 수 없습니다.

따라서 포인트 2는 POST 된 새로운 비밀번호를 나타내는 데이터가됩니다.

포인트 3은 요청을 승인해야 함을 의미합니다. 즉, 사용자가 현재 사용자 인 경우 현재 비밀번호를 확인해야합니다 (해시 기반 도전과 같은 경우 반드시 현재 비밀번호를받을 필요는 없음) 보내지 않고 지식을 증명하는 데 사용되었습니다).

URI는 그러므로 같은 것을해야한다 <http://example.net/changeCurrentUserPassword>또는 <http://example.net/users/joe/changePassword>.

POST 데이터 및 사용중인 일반 권한 부여 메커니즘에서 현재 비밀번호를 수신하기로 결정할 수 있습니다.

답변