현재 HTTPS (즉 SSL 암호화 됨)를 통해 작동하는 PHP OpenID 공급자를 개발 중입니다.
패스워드를 일반 텍스트로 전송하려면 이 (가)이 맞습니까? 이론적으로는 HTTPS가 가로 챌 수 없기 때문에 잘못된 것은 아무것도 없습니다. 아니면 어떤 수준에서는 안전하지 않습니까? 나는 이것을 보지 못하고 있습니까?HTTPS를 통한 일반 텍스트 암호
답변
안전합니다. 그것이 전체 웹이 작동하는 방식입니다. 양식의 모든 비밀번호는 항상 일반 텍스트로 전송되므로 보안을 위해 HTTPS를 사용합니다.
HTTP가 사용 중지 된 경우 에만 HTTPS를 사용하면 패스워드를 일반 텍스트로 전송하지 않습니다.
GET이 아닌 POST 요청을 통해 전송하는지 확인해야합니다. GET 요청을 통해 보내면 사용자의 브라우저 기록 로그 또는 웹 서버의 액세스 로그에 일반 텍스트로 저장 될 수 있습니다.
네, 그 사실을 알았지 만 여기를 보러 오는 사람들에게 남겨 두는 것이 여전히 좋은 의견입니다. :) – WhyNotHugo
다른 포스터는 정확합니다. 이제 암호의 전송을 암호화하는 SSL을 사용하고 있는지, 확인이 너무, 나머지에서 을 때 보호, 그래서 당신이
그래, 나는 이것을 깨닫는다, 고마워, 나는 단지 여기의 전달을 언급하고 있었다. – WhyNotHugo
해시 클라이언트 ... 좋은 알고리즘과 소금을 해시하고 있는지 측면. 왜? 조금만 실험 해 보겠습니다. 회사 식당에있는 컴퓨터에 걸어보십시오. 브라우저를 회사 웹 사이트 로그인 페이지 (https)로 엽니 다. F12 키를 누르고 네트워크 탭을 클릭하고 지속 로그를 선택 해제하고 콘솔을 최소화하지만 웹 페이지를 로그인 페이지로 열어 두십시오. 앉아서 점심을 먹으십시오. 직원이 회사 웹 사이트에 로그온하고 좋은 작은 작업자가 완료되면 로그 아웃 한 후 직원으로 관찰하십시오. 점심 식사를 마치고 컴퓨터에 앉아 네트워크 탭을 열고 모든 단일 사용자 이름과 암호를 bodys 형식의 일반 텍스트로 봅니다.
특수 도구가 없으며 특수 지식이없고 특별한 해킹 하드웨어가 없으며 키로거가 없습니다. 그냥 오래된 F12입니다.
하지만 이봐 요, 당신이 필요로하는 모든 것이 SSL이라고 계속 생각하십시오. 나쁜 놈들이 너를 사랑해.
카페테리아 코멘트는 아무리 많이 읽을지라도 말이되지 않습니다. 사람들이 컴퓨터에 가서 자격 증명을 입력하는 이유는 무엇입니까? 너 무슨 증명하려고? 또한 해싱이 어떤 방식 으로든 * 더 * 안전하지는 않습니다. 이 질문이 2009 년에 작성되었을 때 비밀번호를 해시하고 일반 텍스트 HTTP를 통해 전송하는 것은 일반적인 일이었습니다. – WhyNotHugo
나는 수긍 할 수있는 대답을 몇 년 후에 읽을 수 있기 때문에 두 가지 모두 upvoted했습니다. @CodeDog가 완화 전략을 지적하면 좋을 것입니다. 그리고 예, 사람들은 예를 들어 지역 도서관에서 임의의 PC로 걸어 가서 세부 정보를 입력합니다. – JoeAC
공개 키로 클라이언트 측의 암호를 암호화 한 다음 암호화 된 암호 만 양식에 게시합니다. 비대칭 키이므로 클라이언트 쪽 공개 키를 사용하면 공격자가 쓸모가 없습니다. 모든 로그는 새 키 쌍을 생성하므로 재생 공격은 작동하지 않습니다. 실패한 로그인 시도에서도 키가 변경됩니다. 키 쌍은 사용자가 로그인 화면에 도달하면 서버 측에서 생성됩니다. 클라이언트 측 코드에는 공개 키만 제공됩니다. – CodeDog
- 1. https를 통한 Wcf의 일반 텍스트 사용자 이름 인증
- 2. Django.contrib.auth 만들기 일반 텍스트 암호
- 3. HTTPS를 통한 메시징
- 4. HTTPS를 통한 Google 차트
- 5. https를 통한 안드로이드 ksoap2
- 6. HTTPS를 통한 SWF로드
- 7. WCF 서비스의 메모리에 일반 텍스트 암호 캐싱
- 8. 해독 암호 텍스트 키, 일반 텍스트를 알고,
- 9. HTTPS를 통한 CouchDB 복제 사용
- 10. Nodejs, https를 통한 인증 및
- 11. https를 통한 .js 파일의 동시로드
- 12. HTTPS를 통한 TeamCity 및 JIRA
- 13. https를 통한 WCF 서비스 호출
- 14. WCF 수동 SOAP POST (Usertoken을 통한 https를 통한 HttpWebRequest 사용)
- 15. HTTPS를 통한 클라이언트 인증서를 통한 WCF 요청 인증
- 16. HTTPS를 통한 openbase_dir 제한을 어떻게 비활성화합니까?
- 17. HTTPS를 통한 ASP.NET의 세션 쿠키 보안
- 18. 비보안 항목을로드하는 HTTPS를 통한 Facebook JavaScript SDK
- 19. NTLM에서 HTTPS를 통한 HttpWebRequest가 작동하지 않습니다.
- 20. HTTPS를 통한 파일 업로드 - 데스크톱에서 웹 서버
- 21. https를 통한 REST 웹 서비스 사용
- 22. Python 2.6.1의 urllib2는 https를 통한 프록시를 지원합니까?
- 23. http 페이지에서 https를 통한 Ajax 게시
- 24. base64 일반 텍스트 사용자 이름 및 암호 란 무엇입니까?
- 25. 암호 입력 문자열을 일반 텍스트 또는 해시로 확인할 수 있습니까?
- 26. 변환 텍스트/일반 텍스트
- 27. Java에서 HTTP를 통한 일반 텍스트 트랜잭션을 인증하는 방법을 권장 하시겠습니까?
- 28. 원래 암호 텍스트 저장
- 29. 일반 도우미를 통한 코드 계약
- 30. 사용자 입력을 통한 암호화/암호 해독
사소한 문제점 : 일부 로그인 양식은 JavaScript를 사용하여 일반 텍스트 대신 암호를 해시합니다. – Thorarin
@Thorarin 그들이 진정으로 해시하는 경우 서버가 일반 텍스트로 암호를 저장하므로 동일한 소금으로 해시하여 확인할 수 있음을 의미합니다. Ick! 서버가 암호를 일반 텍스트로 저장해야 할 필요가 없기 때문에 ssl 줄 바꿈 텍스트에서 암호를 보내는 것이 좋습니다. – DGM
@DGM : 이중 해싱도 옵션이므로 일반 텍스트 암호는 반드시 필요하지 않습니다. – Thorarin