세션의 "비밀" 옵션은 무엇입니까?

세션의 "비밀" 옵션은 무엇입니까?

저는 암호학에 대해 아무것도 모릅니다.세션 비밀이 무엇인지 궁금합니다.

다음과 같은 코드가 표시됩니다.

app.use(express.session({
  store: mongoStore({
    url: app.set('db-uri')
  }),
  secret: 'topsecret'
}));

비밀은 무엇이고 제가 그것을 바꿔야 합니까?

네, 바꾸셔야 합니다.연결된 세션 암호는 해시를 계산하는 데 사용됩니다.문자열이 없으면 세션에 대한 액세스가 "거부"됩니다.연결 문서를 살펴보세요. 조금은 도움이 될 겁니다.

이 암호는 HMAC와 세션을 해시하는 데 사용됩니다.

https://github.com/senchalabs/connect/blob/master/lib/middleware/session.js#L256

그런 다음 암호를 사용하여 해시에 대한 지문을 확인하여 세션 하이잭으로부터 세션을 보호합니다.

https://github.com/senchalabs/connect/blob/master/lib/middleware/session.js#L281-L287

이 답변에 대한 동기부여

다른 답변은 "변경해야 합니까?"를 다루고 "무엇입니까?"에 대한 표면적인 설명을 제공합니다.이제 막 사용하기 시작한 사람으로서express-session저는 호기심이 많았고 독서를 하면서 이런 비밀을 갖는 것이 가치 있는 것인지, 얼마인지에 대해 많은 의견 차이를 발견했습니다.

이 주제를 논의하는 많은 사람들은 저와 같은 보안 초보자인 것 같습니다.하지만, 저는 비밀의 의도된 효과와 몇 가지 가능성에 대한 포괄적인 설명과 함께 이 대답을 접하게 되었습니다.당신은 전체 답을 읽어야 하지만, 제가 요약하도록 노력하겠습니다.

그 비밀은 무엇으로부터 보호합니까?

여기서 문제가 되는 공격 유형은 세션 하이재킹입니다.일반적으로 공격자는 유효한 사용자의 세션 ID를 획득하여 해당 사용자의 세션을 에뮬레이트할 수 있으며 공격자가 정보에 액세스하거나 공격 대상자를 대신하여 작업할 수 있습니다.

세션 하이재킹을 방지하려면 어떻게 해야 합니까?

공격자가 ID를 추측하는 능력을 억제하기 때문에 충분히 길고 임의인 세션 ID를 사용하는 것이 좋습니다.다른 답변의 작성자가 언급한 바와 같이:

또한 카운터와 같은 예측 가능한 알고리즘을 사용하여 세션 ID를 생성하지 않는 것이 중요합니다. 이러한 논리가 존재하는 경우 공격자는 더 이상 추측하지 않고 세션 ID를 생성하기 때문입니다.

예를 들어, 공격자가 세션 ID가 순차적이라는 것을 알게 되면(예: 1, 2, 3), 세션 ID가 2인 경우에는 1과 3도 세션 ID라고 가정할 수 있습니다.

가 입니까?express-session의 비밀은?

Express 세션 미들웨어...는 세션 ID와 암호를 조합하여 해시를 계산합니다.해시를 계산하려면 암호를 소유해야 하므로 공격자는 암호를 추측하지 않고는(또는 해시를 추측하려고만 하면) 유효한 세션 ID를 생성할 수 없습니다.

그래서 그 비밀은 길고 무작위적인 해시를 만드는 데 사용됩니다.세션 ID가 이미 충분히 길고 임의인 경우 이러한 방식으로 암호를 사용하는 것은 대부분 중복됩니다.다른 사용자들이 지적했듯이, 결국 공격자는 다른 공격자 대신 길고 무작위적인 추측을 하고 있을 뿐입니다.

하지만 해싱의 사용을 그렇게 빨리 무시하지는 마세요!

express-session는 공개 입니다.

Express 세션 미들웨어의 중요한 기능은 사용자 생성 세션 ID를 지원한다는 것입니다.이를 통해 개발자는 완전히 다른 플랫폼에 상주할 수 있는 기존 엔터티가 세션 ID를 생성하는 기존 환경에서 미들웨어를 배포할 수 있습니다.사용자가 제공한 세션 ID에 해시를 추가하지 않으면 보안 시스템 구축 부담이 전문가(모듈 작성자)에서 사용자(보안 초보자일 가능성이 높은)로 이동합니다.내부 세션 ID 생성기를 강제로 실행하는 것보다 해시를 적용하는 것이 훨씬 더 나은 방법입니다.

경험이 부족한 사용자가 대신 자신의 안전하지 않은 세션 ID 생성기(예: 위에서 설명한 대로 순차적인 것)를 정의하면 해시가 해당 보안 결함을 개선할 수 있습니다.

저자가 다른 곳에서 언급했듯이:

또한, 이 모듈은 광범위한 사용자의 핵심 요구사항을 가정한 일반 모듈입니다.어떤 사람들은 그것을 제대로 사용하지 못할 것이라고 가정해야 합니다(예: 증분 ID).이는 또한 광범위한 사용자를 위한 모듈을 구축할 때 일반적인 관행입니다.

모든 것을 한 바구니에 담지 마.

암호를 사용하는 해시는 보안의 한 계층이며 다른 계층의 결함을 처리하는 데 도움이 될 수 있습니다.임의 세션 ID 생성기에 악용될 수 있는 버그가 있으면 어떻게 합니까? 당신이 실수로 경우사한용을 한다면?RNG.pseudoRandomNumber()대신에RNG.strongRandomNumber()코딩할 때?당신의 의존성 중 하나가 깨지거나 손상되면 어떻게 합니까?다시 한 번 말하지만, 해싱은 이러한 결함을 수정하는 데 도움이 됩니다.

다른 이점들이 있습니다.

만료되었거나 할당되지 않은 ID와 잘못된(악의적으로 생성된) ID 간의 차이를 감지할 수 있습니다.

서버는 해시 또는 서명을 통해 세션 ID에 무결성 구성 요소를 포함함으로써 만료된 세션, 할당되지 않은 세션 ID 및 잘못된 세션을 즉시 구별할 수 있습니다.유효하지 않은 인증 시도만 기록하는 경우에도 유효하지 않은 세션과 다르게 만료된 세션을 기록할 수 있습니다.

ID에 변조 방지 타임스탬프를 작성할 수 있습니다.

쿠키에는 만료 정책이 함께 제공되지만 실제로 이 정책이 준수되는지 확인할 방법은 없습니다. (...) 일반적인 모범 사례는 임의로 생성된 세션 ID에 타임스탬프 접미사를 추가하는 것과 같이 발급된 모든 자격 증명에 타임스탬프를 포함하는 것입니다.그러나 이 타임스탬프를 사용하려면 해당 타임스탬프가 해시 또는 서명으로 처리되지 않았는지 확인할 수 있어야 합니다. (...) 세션 ID에 타임스탬프를 추가하면 서버가 값비싼 데이터베이스 조회를 수행하지 않고도 만료된 세션을 신속하게 처리할 수 있습니다.

문제가 발생하면 즉시 많은 ID를 무효화할 수 있습니다.

해시 또는 서명을 생성하려면 서버 측 암호 또는 키가 필요하므로 암호를 바꾸면 모든 세션 ID가 즉시 유효성 검사에 실패합니다.다양한 유형의 세션 ID에 대해 서로 다른 암호를 사용함으로써 전체 세션 클래스를 분리하고 관리할 수 있습니다.이러한 메커니즘이 없으면 애플리케이션 자체가 각 세션의 상태에 대해 계산된 결정을 내리거나 대량 데이터베이스 업데이트를 수행해야 합니다.

결론적으로

암호를 가지고 있고 해시에 사용하는 것은 다음과 같은 암호를 사용하면 암호를 해시할 수 있습니다.

1. 사용자를 자신으로부터 보호합니다.
2. 추가적인 방어 계층을 추가합니다.
3. (사용자 지정 세션 ID 생성기 사용)악의적인 행동을 탐지할 수 있습니다.
4. (사용자 지정 세션 ID 생성기 사용)ID에 타임스탬프를 번들할 수 있습니다.
5. 킬 스위치를 제공합니다.

그리고 다시 한 번, 저는 이 게시물의 모든 것에 대해 이 답변을 신뢰하고 싶습니다.나는 그저 호기심 많은 구경꾼일 뿐입니다!

언급URL : https://stackoverflow.com/questions/5343131/what-is-the-sessions-secret-option