은행 비밀번호가 왜 그렇게 취약합니까?

Question

흥미로웠고 그것이 나를 화나게 했기 때문에 여기 누군가가 은행에서 일하게 되거나 다른 방법으로 이에 대한 답을 알고 있는지 궁금했습니다.

저는 몇 개의 온라인 뱅킹 사이트(영국 및 북미)를 사용해 보았는데, 그들은 보편적으로 다음과 같은 비밀번호 패턴을 시행합니다. /[\w\d]{6,8}/ 때로는 밑줄을 사용할 수도 있지만 결코 밑줄을 사용할 수는 없습니다. /.{6,20}/ 당신이 접하게 될 거의 모든 !뱅킹 사이트에서 (다소간) 얻을 수 있는 것입니다.

나는 이것이 저장 공간과 관련이 있다고 들었지만 수학은 그것을 뒷받침하지 않는 것 같습니다.은행이 비밀번호 기록을 위해 섀도우 테이블을 유지한다고 가정하면, 계정당 평균 10개라고 넉넉하게 가정하고, 비밀번호의 허용 길이를 두 배로 늘리고 기존 8char 8bit 형식을 기반으로 문자 집합의 비트 너비를 두 배로 늘리면 추가의 11*2*8 = 계정당 176바이트이므로 1M 계정당 ~168Mb입니다.1억 개의 계좌를 지원하는 거대한 은행이라고 가정해 보겠습니다. 이는 여전히 16GB에 불과합니다!

그렇게 간단할 수는 없잖아요?확실히 내 전화 번호는 기본에서 벗어났습니다.

아니면 은행이 은행이기 때문에 공룡을 터벅터벅 걷는 것보다 더 나은 이유가 없다는 대답이 여기에 있습니다.

www.random.com/forum의 비밀번호가 은행 비밀번호보다 강력한 기술적인 이유를 아는 사람이 있나요?

Answer 1

나는 실제로 지금 은행에서 일하고 있으며 과거에는 꽤 많은 일을 해왔습니다.

이런 일이 발생하는 주된 이유는 일반적으로 이러한 결정을 내릴 책임이있는 사람들은 결국이를 시행하는 사람들이 아니기 때문입니다. 은행의 "사업부"는 이러한 결정을 내리는 비 기술적 비즈니스 전문가입니다. 많은 경우에, 정치적 또는 사업적인 이유로 기술적 반대가 무시 될 것이다. 그러나 이것은 은행에만 해당되지 않습니다. 기술적 고려 사항이 종종 주요 관심사가 아닌 산업에서 발생합니다.

Answer 2

제가 특정 은행에서 들은 이야기가 사실이라면...

비밀번호를 입력할 때마다 다음과 같은 이유가 있습니다.

• 웹 서버는 1989년 은행 관리자가 사용했던 UI(Borland C 1.0의 사용자 정의 해킹 버전을 사용하여 컴파일)를 실행하면서 0.5km 길이의 직렬 케이블을 버려진 사무실에 있는 오래된 386에 보냅니다. 직렬 인터페이스가 없으므로 AT 키보드의 키 누르기를 시뮬레이션하는 다른 장치를 거쳐야 합니다.
• 이 프로그램은 귀하의 비밀번호(더 이상 사용하기에는 너무 약하지만 소프트웨어에서 비활성화할 수 없는 사용자 정의 알고리즘을 사용하여 암호화됨)를 포함한 귀하의 요청을 반대편 끝에 있는 다른 버려진 사무실에 있는 NetWare 파일 서버의 FoxPro 데이터베이스에 삽입합니다. 건물 (그냥 옮기려고 하면 산산조각이 나기 때문입니다.)
• 첫 번째 버려진 사무실로 돌아가면 또 다른 오래된 386이 FoxPro 데이터베이스에서 새로운 기록을 지속적으로 폴링하고 이 요청을 감지하고 훨씬 느린 직렬 케이블(이번에는 EBCDIC)을 통해 PDP11을 실행하는 세 번째 사무실의 다른 상자로 전달합니다. 계정을 유지 관리하는 실제 COBOL 프로그램.
• 불행하게도 그들은 여전히 진짜 PDP11에는 또 다른 보안 암호화 알고리즘을 위한 맞춤형 마이크로코드가 있었기 때문에(추출할 수 없거나 변조 방지 장치가 이를 지울 것입니다.) PDP11은 1981년(해당 해) 이후 개설된 모든 계정의 증가된 작업량을 처리할 수 없습니다. 첫 번째 폐기 시도 실패) 이제 (화면 스크레이퍼 및 에뮬레이트된 하드 디스크의 다른 계층을 통해) 주 서버를 대신하여 기능의 하위 집합(암호 확인 포함)을 수행하도록 속입니다.

따라서 귀하의 비밀번호는 이러한 모든 시스템에서 지원하는 문자 세트의 공통 하위 세트만 사용할 수 있으며 관련된 가장 짧은 데이터베이스 필드만큼만 길 수 있습니다.

Answer 3

은행은 온라인 서비스를 주로 레거시 시스템의 인터페이스로 사용합니다. 귀하의 암호는 COBOL로 작성된 IBM 메인 프레임에 의해 처리 될 수 있으며, 비밀번호 구조는 70 년대에 설계되었을 수 있습니다.

또한, 은행은 그러한 정치 구조이기 때문에 경영진은 주로 "콘크리트"결과를보고 있으므로 보안과 같은 문제는 뜨거운 문제가 될 때까지 해결되지 않아서이를 해결하기위한 "이니셔티브"가 있습니다.

내가 일한 한 은행에서 생산 암호는 userID와 동일했습니다 ( "루트" "루트"로 로그인하는 것과 동일). 사용자 비밀번호는 SSN의 성 + 마지막 4 자리 숫자로 온라인으로 온라인으로 재설정 될 수 있으므로 모든 사용자가 이름과 SSN 및 Loginas를 알고 있으면 암호를 재설정 할 수 있습니다.

Answer 4

아마도 대부분의 은행 시스템은 오랫동안 8 개의 문자 암호가 확보 된 것으로 간주되었을 때 개발되었을 것입니다. 어쨌든 은행 계좌에서 Brute 강제 암호를 고려하지 않을 것이라고 생각합니다. 나는 3 번의 시도 후에 모든 은행이 계정을 차단할 것입니다.

Answer 5

다음은 최근에 고객을 위해 구축 한 사이트에 대해 Bugzilla에 로그인 한 "버그"입니다 (은행이 아니라) :

"사용자는 나에게 약간 이상하게 보이는 비밀번호*에 A! 또는 _를 사용해야하는 것 같습니다.이 벤은 알파 너머리만을 사용할 수있는 6-8 자리 암호로 업데이트 될 수 있습니까?"

• 사실, 그것은 적어도 하나의 비 알파 숫자 문자였습니다.