2011-01-25 2 views
1

안전한 결제 포털을 구축 중입니다.자동 로그인, 긴 URL, 암호화

현재 두 가지 응용 프로그램이 있습니다. 하나는 웹 응용 프로그램이고 다른 하나는 데스크톱 응용 프로그램입니다. 이 두 가지 모두 사용자가 로그인/인증해야하며 동일한 자격 증명을 두 응용 프로그램에 사용할 수 있습니다.

다양한 로그인/주문 세부 정보를 모두 채우고 위에서 언급 한 두 앱에서이를 호출 할 수있는 자동 로그인 메커니즘을 만들고 싶습니다. 나는이 일을하는 가장 좋은 방법은 URL을 통해 암호화 된이 정보를 전달하는 것이라고 생각해 왔습니다. ie https://mysite.com/TakePayment.aspx?id=GT2jkjh3 ....

Google은 PCI 범위를 줄이기 위해 지불 처리를 데스크톱 응용 프로그램에 너무 밀접하게 통합하고 싶지 않으므로 브라우저를 통해 중앙 보안 지불 페이지로 브라우저를 열도록 결정했습니다. 간단한 쉘은 전체 URL로 실행되어 기본 브라우저가 해당 페이지를 열게합니다.

원래 우리는 AES를 암호화에 사용하고 있었지만 이것은 최종 사용자에게 키를 제공 할 필요가 없기 때문에 현재 재검토 중입니다 (AES는 대칭이며 대칭 암호화 = 양쪽 모두 개인 키가 필요함). 왜 우리가 응용 프로그램을 배포 할 예정이기 때문에 암호화하는 것까지 신경 쓰지 않습니까?) 그래서 .NET에서 내장 RSA 루틴을 사용하여 공개 키 암호화를 사용하도록 전환하려고합니다.

RSA 부분에서 키 길이에 대해 사용 된 대부분의 예제에서 키 길이에 대해 1024 비트를 사용 했음에도 불구하고이 키를 사용하여 공개 키 암호화를 사용하는 포털을 만들었지 만 생성 된 URL은 AES를 사용했을 때보 다 훨씬 길기 때문에 URL의 최대 한도를 조사하고 있습니다. http://www.boutell.com/newfaq/misc/urllength.html IE가 경로 부분에 약 2048 자의 제한 브라우저라고합니다. RSA 암호화를 사용한 초기 테스트 결과 내 URL은 약 1400 자 정도 될 것입니다.

내 질문이 졸이다 :

1) 내가 생각하고 있지 않다 웹 사이트에 데스크톱 응용 프로그램에서 정보를 전달하기위한 더 좋은 방법이 있나요? 데스크톱에서와 마찬가지로 다른 웹 페이지에서도 쉽게 사용할 수 있기를 바랍니다. 그러므로 현재의 솔루션입니다.

2) 1024 비트 RSA 키가 필요합니까? 또는 이와 같은 것을 과잉 살상습니까? 짧은 키는 짧은 암호화 된 텍스트를 의미합니까?

3) 1200-1400 자 범위의 URL과 관련하여 예기치 않은 문제가 있습니까? 프록시? 방화벽? 웹 가속기?

감사

업데이트 2011년 12월 11일 : 가 찾아 와서, 오늘날 우리가 대해 여기로가는 결국 최근 엉덩이에 우리를 물고 결국 (또는 오히려 우리가 발견하는 방법 비록 문제가 추적하기가 매우 산발적이고 어려운 것이지만).

우리가 암호화 한 평범한 텍스트 토큰은 원래 약간 작았으며 단지 100 바이트 정도였습니다. 이것이 테스트 URL의 길이가 약 1400 바이트가되는 결과입니다. 기능 크리프를 통해 우리는 토큰에 더 많은 데이터를 추가해야하며 평균 URL 길이는 1700-1800로 뛰었습니다.

일반 텍스트의 길이가 173자를 초과하면 URL 길이가 다시 점프되며 이번에는 2080+ 이상으로 증가하여 IE에 문제가 발생합니다. RSA 암호화가 어떻게 작동하는지에 대한 조사가 있긴했지만, 이는 완전히 예상 된 것이었지만 원래는 내 부분에 대한 감독이었습니다.

우리는 1024 비트 RSA 암호화를 사용하고 있습니다. 즉, 암호화 할 수있는 최대 데이터 블록 크기는 1024/8 - 24 = 86 바이트이고, 모든 86 바이트는 "잘려서"따로 암호화해야합니다. 86 * 2 = 172에서 우리는 3 블록, 4 블록, 5 블록 등을 암호화하는 것보다 2 블록 만 암호화합니다. 172를 전달하면 암호 텍스트 길이가 길어져 URL이 너무 길어집니다. 아마도 여기에 약간의 설명을 엉망으로 만든 것 같습니다. 그러나 그것의 일반적인 요점은 ..

우리는 이것이 더 잘 작동하도록 설계 할 것입니다. 기대할 수있는 것처럼 " 더 많은 기능 "이 향후 추가 될 예정이므로 토큰은 계속 커질 것입니다.

답변

0

이것이 모두 데이터베이스에 로그인되었다고 가정하면 SSL 웹 서비스를 사용하여 데이터를 앞뒤로 전달할 수 없습니다. 그런 다음 데스크톱 응용 프로그램에서 웹 응용 프로그램으로 신속하게 이동할 수있는 경우 임의의 키를 생성하기 위해 웹 사이트로 RPC 호출을하고이를 사용자에게 전달하고이를 사용하여 웹 페이지를 호출합니다. 10 초 동안 키를 유효하게 만드십시오. 키를 캡처하여 깨뜨린다면 유효하지 않게됩니다.

저는 이런 종류의 경험이 거의 없기 때문에 아이디어에 많은 구멍이 뚫릴 것으로 예상됩니다.

+0

현재 애플 리케이션이 중앙 DB를 공유하지 않는다는 것을 제외하고는 백엔드 DB가 가능한 해결책이 될 수 있다고 생각 했었습니다. 그리고 데스크탑/웹 앱을 결제 포털 DB에 절대 최소로 유지하는 것을 선호합니다. 그래도이 길로 갈 수 있습니다. 키 타임 아웃은 좋은 아이디어이며, 이미 구현되어 있습니다 (특정 시간대 밖에서 암호화 된 값을 사용하려고 시도하면 웹 사이트가 해당 시도를 거부합니다) –