HTTPS없이 로그인, 보안 방법은?
웹 애플리케이션의 경우 HTTPS를 보안 조치로 사용할 수없는 경우에도 로그인을 어느 정도 보안 할 수 있습니까? 예 :
- 반복 공격을 어렵게 만들기 위해 로그인을 토큰 화합니까?
- HTML 암호 필드에서 보낸 암호를 어떻게 암호화합니까?
특히 저는 CakePHP와 AJAX POST 호출을 사용하여 인증을 트리거하고 있습니다 (제공된 사용자 이름과 암호 포함).
문제에 대한 업데이트 :
- HTTPS를 사용할 수 없습니다. 기간. 상황이 마음에 들지 않으면 이론적 인 질문으로 간주하십시오.
- 명시적인 요구 사항이 없으며, 실제 생활에서 제공하는 HTTP, PHP 및 브라우저 (쿠키, JavaScript 등)가 무엇이든 보유하고 있습니다 (매직 RSA 바이너리, PGP 플러그인 없음).
- 질문은 당신이 밖으로 만들 수있는 가장 좋은 무엇이며, 이 암호가 일반 텍스트로 보내는 것보다 더 나은 상황. 그러한 각 솔루션의 단점을 아는 것은 장점입니다.
- 일반 비밀번호보다 더 나은 개선은 환영합니다. 우리는 100 % l33tG0Dhx0r-proff 솔루션을 목표로하지 않습니다. 크랙하기 어려운 것이 암호를 드러내는 사소한 스니핑보다 낫습니다.
HTTPS는 웹 사이트와 브라우저 간의 보안 연결을 유지하는 데 절대적으로 중요 합니다. 공용 Wi-Fi 네트워크는 사용자를 위험에 빠뜨리 며 올바르게 사용하면 HTTPS 가이 취약점 으로부터 사용자 계정을 보호 할 수 있는 유일한 도구 입니다 .
호스트가 HTTPS를 지원하지 않는 경우 Cloudflare Universal SSL 과 같은 서비스를 사용 하여 서버가 SSL / TLS를 지원하지 않더라도 모든 브라우저가 HTTPS를 사용하여 사이트에 연결되도록 할 수 있습니다 . Cloudflare와 웹 사이트 간의 연결은 여전히 보호되지 않지만이 Cloudflare 서비스는 공용 Wi-Fi 네트워크에서 발견되는 위협으로부터 사용자를 보호하기위한 것입니다. 침투 테스터의 관점에서 HTTPS를 제공하지 않는 것은 매우 의심 스럽습니다. 트래픽을 전달하는 것과 같은 기본 보안 요구 사항을 제공하지 않는 경우 어떤 다른 보안 요구 사항이 누락됩니까? HTTPS 인증서는 Let 's Encrypt 또는 Start SSL을 사용하여 무료로 얻을 수 있습니다 . HTTPS를 지원하지 않는 합법적 인 이유는 없습니다.
HTTPS는 "암호 암호화"이상의 기능을 수행하기 때문에 매우 중요합니다. 또 다른 중요한 역할은 사용자가 실제 서버를 가장하는 악성 서버에 로그인하는 것을 방지해야한다는 것입니다. 시스템을 사용하여 암호 만 보호 하는 것은 공격자가 필요로하는 모든 세션 자격 증명을 여전히 일반 텍스트 ( Firesheep ) 로 전송하기 때문에 OWASP A9-불충분 한 전송 계층 보호를 위반하는 것 입니다.
"Tokenize logins": 공격자가 트래픽을 스니핑하는 경우 일반 텍스트 사용자 이름 / 암호를 갖게되고 이러한 새 자격 증명으로 로그인 할 수 있습니다. (리플레이 공격)
"어떻게 든 전송 된 암호를 암호화": 사용자가 로그인 한 후 공격자는 트래픽을 스니핑하여 유효한 세션 ID (쿠키) 를 얻은 다음 로그인하는 대신 이것을 사용합니다. 전체 세션이 SSL / TLS로 보호 된 경우 이것은 문제가되지 않습니다.
이 시스템과 현재 SSL 인프라 모두에 영향을 미치는 다른 더 복잡한 공격이 있습니다. SSLStrip의 공격은 더 세부로 들어갑니다. HTTP-Strict-Transport-Security 표준으로 이어지는 Moxie Marlinspike의 Blackhat 2009 강연을 시청 하는 것이 좋습니다 .
웹 서버에서 SSL을 수행 할 수없고 보안 전문가가 아니므로 활용할 수있는 기존 보안 인증 서비스를 찾아서 SSL과 자격 증명 처리의 복잡성을 모두 처리하도록합니다.
특히 OpenID 와 같은 무료 타사 인증 서비스를 사용하는 것이 좋습니다 . 그들은 CakePHP 용 라이브러리를 포함하여 PHP 용 라이브러리를 가지고 있습니다 .
편집 : (위험에 대해)
HTTPS 자체를 사용하는 타사 보안 인증 서비스를 사용하면 HTTPS (서버에서)를 사용하지 않고 인증 자체 문제를 완화 할 수 있지만 공격 가능성을 완전히 제거하지는 못합니다.
가장 일반적인 두 가지 공격은 재생 공격과 공격자가 나중에 정품 로그인 세션 토큰을 재사용하거나 악의적 인 목적으로 유효한 세션 토큰을 사용할 수있는 세션 하이재킹 입니다.
재생 공격은 세션 토큰이 만료되도록함으로써 완화 될 수 있으며, 가급적이면 nonce 를 사용하여 세션 재생을 방지하고 세션 하이재킹의 위험을 줄입니다. nonce를 사용하면 nonce가 만료 (사용)되어 자신의 세션이 더 이상 유효하지 않기 때문에 정상적인 세션이 성공적으로 하이재킹되면 오류를 생성합니다.
HTTPS를 사용하여 서버에서 전송되는 동안 세션 토큰을 암호화 할 수없는 경우 세션 하이재킹 또는 중간자 공격 과 같은 활성 공격을 완전히 차단할 수 없습니다 . 이는 비상업적 인 용도로 사용자 기반이 적은 웹 사이트와 같은 경우에 허용 될 수 있습니다.
짧은 대답은 SSL 끝점에서 끝점으로의 암호화 없이는 안전하게 수행 할 수 없다는 것입니다.
이에 대한 주된 이유 중 하나는 브라우저에서 보안 암호화를 수행 할 수 없기 때문입니다. 이 참조-유해한 것으로 간주되는 Javascript 암호화를 참조 하십시오 .
또한 자격 증명의 출처가 실제로 귀하가 대화하는 사람인지 확인할 수있는 방법이 없습니다. 즉, 중간자 공격이 진행 되지 않도록 SSL 없이는 절대 방법이 없습니다 .
그래서 아니, 당신은 그것을 할 수 없습니다.
또한 시도하지 마십시오. SSL을 가져옵니다. 무료 인증서를받을 수 있습니다. 호스트는 일반적으로 월 $$$에 전용 IP를 제공합니다. 그리고 보안에 대해 정말로 관심이 있다면 어쨌든 전용 IP 주소가있는 VM을 최소한 사용하고있을 것입니다.
이것을 시도하는 것은 기껏해야 은밀한 보안을 통한 보안 이며 최악의 경우는 없습니다. SSL은 해결 된 문제입니다. 그 솔루션을 사용하지 않는 이유는 무엇입니까? 보안은 추측 할 수 없습니다. 적절한 기술을 사용하십시오. 자신의 것을 발명하려고하지 마십시오. 작동하지 않습니다 ...
제안한대로 페이지가 생성 될 때마다 고유 한 토큰을 생성 할 수 있습니다. 동일한 토큰을 양식 데이터와 함께 다시 보내야하며 재사용 할 수 없습니다. 사용자가 활성화 할 수있는 경우 JavaScript를 사용하여 해시하여 암호를 안전하게 유지할 수도 있습니다.
그러나이 체계는 여전히 안전하지 않습니다. 공격자는 여전히 전선을 가로 지르는 모든 것을 볼 수 있습니다. 그들은 토큰을 가로 채서 사용자가하기 전에 응답을 보낼 수 있습니다. 또는 누군가가 로그인 할 때까지 기다렸다가 해당 사용자의 자격 증명을 훔친 다음 (유선으로 전송 됨) 나중에 자신의 로그인 요청을 할 수도 있습니다.
결론 -사이트의 보안을 보장하려면 HTTPS를 사용해야합니다.
Javascript를 사용하여 암호를 암호화하고 서버에서 암호를 해독 할 수 있습니다.
서버에서 RSA 키 쌍을 생성하고 시간 제한 솔트와 함께 공개 키를 브라우저에 보낸 다음 Javascript의 공개 키를 사용하여 솔트와 결합 된 암호를 암호화하는 것이 좋습니다.
여기 에서 Javascript 에서 RSA 구현을 찾을 수 있습니다.
프록시 뒤에서 쿠키 도난을 방지하기 위해 인증 쿠키에 IP 주소와 전체 X-FORWARDED-FOR 헤더를 모두 포함해야합니다 .
민감한 데이터를 처리하는 경우 Javascript 로 임의의 AES 키를 생성 한 다음 RSA로 암호화 된 비밀번호와 함께 서버로 전송할 수 있습니다.
그런 다음 전체 애플리케이션이 단일 페이지에서 암호화 된 AJAX 요청을 사용하고 인증 쿠키를 전혀 사용하지 않도록 할 수 있습니다.
SSL 없이는 활성 중간자 (man-in-the-middle) 공격으로부터 보호 할 수 없습니다. 적극적인 공격자는 사이트를 자신의 프록시로 완전히 교체 할 수 있으며이를 방어 할 방법이 없습니다. (알려진 좋은 코드가 없기 때문에)
대부분의 브라우저에서 지원되며 유선을 통해 암호를 일반으로 전송하지 않는 HTTP Digest 인증을 사용할 수 있습니다 .
단점은 broswer가 표시하는 못생긴 로그인 상자입니다. 양식을 선호하는 경우 양식 인증에서 HTTP Digest와 똑같은 프로토콜을 구현할 수 있습니다. 영역과 챌린지를 포함하는 숨겨진 필드를 보내고 클라이언트가 임시 값을 JavaScript에 추가하고 다이제스트를 계산하도록 할 수 있습니다. 이 방법을 사용하면 직접 롤링하는 대신 잘 알려져 있고 입증 된 확장 프로토콜을 사용할 수 있습니다.
HTTP Digest에는 해시 작업 만 필요합니다.
무엇에 대한 HTTP 다이제스트 인증 ? 서버로 보내기 전에 MD5 해싱 사용자 이름, 암호 및 임시 값 (특히)으로 보안을 제공합니다. MD5는 실제로 안전하지는 않지만 HTTP를 사용한 간단한 보안에는 좋은 방법입니다.
물론 이것은 해커가 메시지를 변경하는 것을 막지는 않지만 암호를 보호합니다.
HTTPS에는 수많은 사용 사례가 있으며, 대부분은 중간자 공격을 방어하도록 설계되었습니다. 해커의 사고 방식을 가진 사람은 누구나 무언가를 성취 할 수있는 확립 된 방법 외에 다른 방법이 없다고 말하고 떨릴 것입니다. 사실 TLS (최신 HTTPS가 사용하는 표준)를 사용한다고해서이를 잘 사용하고 있다는 의미는 아닙니다. 또한 TLS를 사용한다고해서 누군가가 알려진 약점을 악용하는 것을 막을 수는 없습니다. 데이터를 보호 할 수있는 창의적인 방법을 찾는 것처럼 보안 조치를 활용할 수있는 창의적인 방법을 찾는 사람들이 있습니다.
그래서 뭘 할건데?
우선, TLS를 포기하려는 경우 작동 방식을 이해하는 것이 도움이됩니다. 그리고 그것은 모두 악수에 관한 것입니다.
클라이언트와 서버가 TLS 사용에 동의하면 핸드 셰이 킹 절차를 사용하여 상태 저장 연결을 협상합니다. [7] 이 핸드 셰이크 동안 클라이언트와 서버는 연결 보안을 설정하는 데 사용되는 다양한 매개 변수에 동의합니다.
- 핸드 셰이크는 클라이언트가 보안 연결을 요청하는 TLS 사용 서버에 연결할 때 시작되고 지원되는 암호 그룹 (암호 및 해시 함수) 목록을 제공합니다.
- 이 목록에서 서버는 또한 지원하는 암호 및 해시 함수를 선택하고 클라이언트에게 결정을 알립니다.
- 서버는 디지털 인증서의 형태로 ID를 다시 보냅니다. 인증서에는 일반적으로 서버 이름, 신뢰할 수있는 인증 기관 (CA) 및 서버의 공개 암호화 키가 포함됩니다.
- 클라이언트는 인증서를 발급 한 서버 (위와 같이 신뢰할 수있는 CA)에 연락하여 계속하기 전에 인증서의 유효성을 확인할 수 있습니다.
- 보안 연결에 사용되는 세션 키를 생성하기 위해 클라이언트는 서버의 공개 키로 난수를 암호화하고 그 결과를 서버로 보냅니다. 서버 만 개인 키를 사용하여 암호를 해독 할 수 있어야합니다.
- 난수에서 양측은 암호화 및 복호화를위한 키 자료를 생성합니다. [모순] 이것은 핸드 셰이크를 종료하고 연결이 종료 될 때까지 키 자료로 암호화 및 복호화되는 보안 연결을 시작합니다.
위 단계 중 하나가 실패하면 TLS 핸드 셰이크가 실패하고 연결이 생성되지 않습니다.
출처 : Wikipedia
그래서 가능할까요? 예. 나는 무엇이든 가능하다고 배웠다. 비쌀 수 있지만 항상 가능합니다.
나는 보안 전문가가 아니라 단지 열성적인 사람임을 완전히 밝히고 싶습니다. 프로덕션 등급 프로젝트 또는 자신의 수정 이외의 다른 용도로 시도하지 않는 것이 좋습니다. 자신의 보안 프로토콜을 설정할 때 장애물에 대한 훌륭한 설명을 제공하는 이 SO 게시물 을 확실히 확인해야 합니다.
그러나 계속 진행하고 싶다면 여기에 떠오르는 몇 가지 생각이 있습니다. 이것은 당신이이 프로젝트에 어떤 지시를했는지에 관계없이 존재하게 될 현실입니다.
HTTPS는 모든 주요 최신 브라우저에서 지원됩니다. 이러한 현실에서도 HTTPS로드 시간은 일반 HTTP보다 느립니다. 광범위한 프로덕션이 없으면 대체 구현이 훨씬 더 느리지 만 보안 수준이 낮을 가능성이 높습니다. 이것은 브라우저 기능을 사용하지 않는 한 모든 자체 구현의 단점이 될 것입니다. 이는 최신 HTTPS가 사용하는 TLS를 사용하는 것으로 다시 돌아옵니다.
MiTM 공격이 어려울 정도로 예측할 수없는 방식으로 Javascript를 사용하여 브라우저 측에서 TLS없이 비밀번호를 암호화 할 수 있다면 거기에서 쉬지 마십시오. 또한주고받는 데이터를 보호해야합니다. 그렇지 않으면 암호화되는 암호는 실제로 관련이 없습니다. 물론 공격자는 bobsmith109의 암호를 모를 수도 있지만 네트워크의 모든 활동을 스니핑 할 수 있기 때문에 필요하지 않습니다. 그는 bobsmith109가 로그인하는 시간을 알고 있으며, 아마도 그의 IP와 당신이주고받는 다른 민감한 데이터를 추적 할 수 있습니다.
어떤 보안 조치를 취하 든 깊이있는 보안이 있습니다. 따라서 즉시 할 수있는 한 가지는 강력한 암호를 요구하면서 데이터베이스의 데이터를 암호화하는 것입니다.
저는 보안 전문가가 아니라는 점을 다시 한 번 말씀 드리며, 귀하의 호기심을 충족시키기위한 것 외에는이를 강력히 권장하지 않습니다 . 수십 년이 아니더라도 수년간 프로젝트에 기여하는 엄청나게 많은 보안 전문가 그룹없이 TLS에 대한 실행 가능한 대안을 만들 수 있다는 것은 천문학적으로 불가능한 일입니다. 이것이 SSL / TLS가 자랑 할 수있는 것입니다. 즉, 계속 진행하기로 선택한 경우 좋은 시작점은 위의 핸드 셰이크 모델을보고 TLS없이이 버전을 구현할 수있는 방법을 확인하는 것입니다.
HTTPS 사용에 대한 대부분의 실제 장벽이 적극적으로 맞서고 있다는 내 게시물을 공유하지 않는 것이 좋습니다. 가장 큰 비용 중 하나는 문제가되지 않는 것에 매우 가깝습니다. 2015 년 2 분기에 무료 인증 기관이 출시 될 예정이며 Mozilla 및 Akamai를 비롯한 일부 거물들이 지원합니다. 여기에 기사가 있습니다.
공개 키 암호화 (GPG)를 사용하고 브라우저 캐싱을 사용하여 특정 지점으로 복제 할 수 있습니다.
이것은 안전한 것이 아닙니다. SSL을 설치하는 것만으로는 정교한 공격자에게는 충분하지 않습니다 . 오늘날 웹 사이트가 안전한 것으로 간주하려면 HSTS, 공개 키 고정 등을 사용해야 합니다 .
나머지 대답은 생각을위한 음식입니다.
- 공개-개인 키 쌍을 만듭니다. 개인 정보를 안전하게 보관하십시오.
- 공개 키와
encrypt함수를 포함하는 js 파일을 만들고 보안 암호화 알고리즘을 찾습니다. 이 함수는 복제 공격을 피하기 위해 추가 타임 스탬프를 사용하여 주어진 문자열 (직렬화 된 형식)을 암호화해야합니다. Cache-Control:public, max-age=31536000HTTP 헤더 와 함께이 파일을 제공하십시오 . 공격자가 스크립트를 교체하려고 할 때이를 완화하려고합니다. 파일은 항상 브라우저 캐시에서 제공됩니다.encrypt함수를 사용하여 Javascript를 통해 모든 양식을 보냅니다 . 위와 동일한 헤더로 제공합니다.- 서버 측
decrypt에서 데이터는 여전히 유효한 경우 타임 스탬프를 확인합니다. 그렇지 않다면 버리십시오. - 매우 짧은 시간 동안 한 번만 사용할 수있는 쿠키 토큰을 만듭니다. 공격자가 쿠키를 캡처하면 작업을 수행 할 시간이 많지 않습니다. 그러나 공격자가 충분히 빠르면 원래 사용자를 로그 아웃 할 수 있습니다.
- 모든 응답으로 쿠키를 변경하십시오. 하지만 사용자가 한 번에 여러 요청을 보낸 다음 역순으로 도착하면 어떻게합니까? 어떤 쿠키가 유효합니까? 이것은 잘못된 보안 감각을 대가로 수많은 문제를 야기합니다.
모든 리스너는 앞뒤로 이동하는 데이터를 사용할 수 없으며 캐시가 만료 되거나 사용자가 캐시를 지울 때까지 기존 JS 파일 을 변경 / 주입 할 수 없습니다 . 그러나 정교한 공격자는 HTML내가 방금 언급 한 모든 보안 측정을 폐기 하는 전체 파일을 대체 할 수 있습니다 . 당신이 적어도 /이 파일을 제공을 통해 형성 할 수 있다면 HTTPS, 당신은 수 , 그것으로 도망 GitHub의 페이지 또는 무엇에 올려. 그러나 파일을 다른 도메인에 넣는 경우 CORS수신 도메인이 작동 하도록 설정해야합니다 .
또 다른 시도
일회성 비밀번호가 이메일로 전송되었습니다.
- 사용자가 이메일을 작성하고 링크를 클릭하면 로그인 할 수있는 토큰이 포함 된 이메일 링크가 전송됩니다.
- 사용자가 링크를 클릭
- 서버가 토큰을 확인하고 사용자를 로그인합니다.
- 이전 예와 같이 쿠키를 롤링합니다.
대체로 무엇을하든 안전하지 않습니다 . 빠르고 정교한 공격자에게 방해가되는 것은 없습니다.
SSL을 가져오고 인프라가 지원하지 않는 경우 변경하십시오. 관리자가 SSL을 믿지 않으면 설득하십시오. 잘못된 보안 감각을 만들지 마십시오. 사용자의 데이터를 보호하려면 위치에 따라 법적으로 사용자의 데이터를 보호해야합니다.
그런 다음 SSL을 사용하여 사이트를 안전하게 만드는 방법에 대해 이야기하겠습니다.
HTTPS없이 로그인, 보안 방법은?
서버와 클라이언트 사이에 보안 채널이 없기 때문에 :
- 보안 채널이 없기 때문에 누구나 트래픽을 스누핑 할 수 있습니다.
- 누구든지 트래픽을 스누핑 할 수 있기 때문에 MITM 공격에 노출되어 있습니다.
- MITM 공격에 노출되어 있기 때문에 클라이언트가 합법적 인 페이지를 볼 것이라는 보장은 없습니다.
- 페이지가 합법적이지 않고 페이지가 실제로 제공되지 않기 때문에 (중간에있는 사람이 페이지를 제공하고 있음) 서버 측에서 사용되는 모든 트릭은 쓸모 없게됩니다.
당신은 무엇을 할 수 있나요? 이론적으로?
- 클라이언트와 서버 모두 스누핑 / MITM의 취약성을 줄이기 위해 암호화를 사용해야합니다.
- 악수를 할 수 없다고 가정하고
- 클라이언트가 이미 키를 가지고 있고 서버와 동일한 의미없는 말을하는 방법을 알고 있다고 가정합니다.
- HTTP를 통한 SSL은 어떻습니까? 그러나 일부 횡설수설을 위해 base64 인코딩 메시지로 래핑되어 있습니까?
하지만 잠깐 ... 마법 바이너리 나 플러그인, RSA도 말하지 않았기 때문에이 중 어떤 것이 (잠재적으로 매우 약한) 사내 암호화를위한 저장이 가능한지 모르겠습니다.
-
"보안 원격 암호 프로토콜"을 살펴보십시오 .
직접 공식화하는 대신 웹 사이트에서 인용하겠습니다.
Secure Remote Password 프로토콜은 사람이 기억할 수있는 짧은 암호의 안전한 원격 인증을 수행하고 수동 및 능동 네트워크 공격에 모두 저항합니다.
과:
[The] 프로토콜은 영 지식 증명 기술과 비대칭 키 교환 프로토콜을 결합하고 Augmented EKE 또는 B-SPEKE와 같은 훔친 검증 자 공격에 저항하는 비교적 강력한 확장 방법보다 훨씬 향상된 성능을 제공합니다.
Stanford University는 PHP 및 JavaScript 자체 구현을 제공하지 않지만 일부 타사 구현에 연결됩니다.
이러한 링크 중 하나 는 온라인 암호 관리자 인 "Clipperz"로 연결됩니다 . GitHub에서 커뮤니티 에디션으로도 제공됩니다. 그곳에서 그들은 프로토콜을 구현하는 "javascript-crypto-library" 와 PHP와 Python으로 작성된 백엔드를 포함 하는 "password-manager" 자체 를 호스팅합니다 .
코드의 관련 부분을 추출하는 것이 얼마나 어려울 지 말할 수는 없지만 구현을 재사용 할 수 있습니다 (AGPL에 따라 라이센스가 부여됨).
2014/10/24 수정 :
SRP에 대한 Wikipedia의 기사 에는 더 많은 구현이 나열되어 있습니다. PHP / JS 관련 :
비대칭 암호를 사용하여 공개 / 개인 키 쌍을 만듭니다.
서버에 대칭 키를 만듭니다.
Send the public key down to the client side.
Create a random key for the symmetric cipher client side.
Encrypt that random key using the public key client side.
Send the encrypted key to the server.
Server does the following:
a. Decrypts the random symmetric key using the private key.
b. Creates a token containing the generated client key.
c. Signs the token.
d. Encrypts the token using the server symmetric key.
e. Encrypts the already encrypted token with the client generated key.
f. Sends the encrypted token down.
The client receives this token and does the following:
a. Decrypts the token with the key it generated.
b. Stores the decrypted token.
c. At this point the stored token is only encrypted with the server symmetric key.
On every from the client to the server:
a. Encrypt the outbound data using the client generated key.
b. Send the token + encrypted data
On every request the server receives:
a. Decrypt the token using the server symmetric key.
b. Verify the signature.
c. Decrypt the data using the client generated key stored in the token.
The best solution I have seen for somewhat secure HTTP connections is to use a Javascript implementation of md5sum (or some other hash) to avoid transmitting the password in plaintext. You can create a form onsubmit handler in Javascript that replaces the password field with a hash of the original value. This adds a modest amount of security to an unsecure connection, but relies on Javascript running in the browser to work properly.
I guess you care about secure transmission of password to the server? My answer is: dont transmit passwords to the server :)
Infact you may not transmit anything from browser (user) to server to authenticate the user, as an attacker who is spying http traffic would also be able to retransmit the data and authenticate.
Proposal:
Obvious solution would be to use a one-way, one-time transaction authentication originating from server; like a transaction number which can only be used once. Eventually, you still need a secure channel once to sync the list of transaction numbers with user.
You could use something google authenticator, yet you need a secure channel once to setup parameters on either side. If you consider email to be secure, that would be a way to go.
I have the same issue on a system of mine. I have taken steps to try and increase security without compromising the user experience with convoluted mechanisms. What I noticed was that the vast majority of users logged in from the same machine using the same browser, (but not necessarily the same IP address), or from a couple of browsers (eg: desktop or mobile). I decided I could use this to identify a pattern.
1) During registration, users are required to have strong passwords (to prevent dictionary attacks), a security question/answer and standard email verification (as proof of real person)
2) During login, after 5 failed login attempts (not before), a captcha is displayed to prevent brute force attacks.
3) Finally, I created a hash of parts of the user-agent string following a successful login, containing the users OS, browser (general not versions) and language - forming a sort of secondary password. If the useragent hash is significantly different on next login, the user is asked to answer the security question. Then, if this is answered satisfactory, the new UA string is hashed and added to their "safe machines" list, so that they wont be asked again from this machine. This is similar to a mechanism employed by the Steam gaming system.
This has been in use for over a year very successfully with about 700 users and it had the additional benefit of preventing "login sharing" - a problem where multiple users were using the same credentials for convenience!
The answer is shorter, and if you really matter about security you always have options that different levels of bureauocracy.
Absolut security does not exists. The number one flaw is always on the client side, with trojans ans keyloggers. SSL doesn't help with that.
1) Token generators: banks use them, blizzard uses then. It can be a device or an app. Well.. it's expensive.
2) SMS pins. interesting and affordable solution. There is a lot of good prices from trnasactional sms on the market and everyone has a phone capable of receiving it.
3) If you have to use HTTP, you can force a third party oauth service, like google or facebook. That's the best you can do without a token generator.
Use hashing mechanisms to store password and always compare the hashed password then nobody knows the real password even you. It is very simple but it is effective.However, nothing is completely secure and there are some ways to broke the scurity layers.
If you can't use HTTPS or you don't want to use HTTPS, consider using jCryption. jCryption offers encryption for the data being sent through HTTP requests (POST, GET etc.).
You can test the technique here: http://www.jcryption.org/#examples
If you're using Firebug, you'll see that all the data is encrypted.
It has jQuery library to encrypt the data on the front-end and a PHP library to decrypt the data in the back-end.
Try this : On each request of the login page, send across a nonce and a timestamp. While posting to server, send the following four details :
The username, the nonce and the timestamp in plaintext. Then concatenate the above with a separator (Eg: newline) and encrypt using the user's password as encryption in chained-block-cipher mode.
On the server end use the username to lookup the password and verify the encrypted string.
Since the password is never sent across in clear, it is secure and the timestamp can be used to avoid a re-submit of the same data.
To avoid hijacking of session by obtaining the session key through a man-in-the-middle attack, the password or a hash of the password can be stored in-memory by the application on the client end and be used for generating unique session keys for validation by server.
Taking a look at OAuth 1.0 is also not a bad idea.
It is hard to secure the communication without a trusted third party, however, there are some security tricks for you:
DO NOT expose users' sensitive information to public network.
Every sensitive information should be well hashed or public-key encrypted. Pay attention: If you choose to encrypt users' sensitive information by a public-key, please make sure that the user can verify the public-key. For example, you could send some kind of public-key fingerprint to user via SMS or even an auto-call.
Generate a SHARED SECRET after log on successfully
After a secure log on transaction, a shared secret should be generate. The generation procedure could refer to SSL Handshake. Pay attention: Once the shared secret is generated, it must on be transported anymore. The only function of it is to encrypt/decrypt the data between Server and Broswer
There SHOULD be a two-step-verification to avoid repeat attack
May these tricks will help you
참고URL : https://stackoverflow.com/questions/2336678/login-without-https-how-to-secure
'Program Tip' 카테고리의 다른 글
| Subversion에서 트렁크를 분기에 병합 (0) | 2020.10.19 |
|---|---|
| 4x4 행렬 반전 (0) | 2020.10.19 |
| 여러 프로세스간에 결과 큐 공유 (0) | 2020.10.19 |
| Angular2에서 이미지를 제공하는 방법은 무엇입니까? (0) | 2020.10.19 |
| C ++ : enum 값을 텍스트로 인쇄 (0) | 2020.10.19 |