쿠키를 세션에 저장하면 악의적 인 클라이언트가 자유롭게 세션을 수정할 수있는 비밀로 암호화해야합니다. 이 디자인은 대중적으로 논의 된 많은 이유로 여전히 나쁘다.서버에 세션 저장소가 있으면 세션 암호는 무엇을합니까?
그러나 서버에 세션을 저장하면 (랙 : 세션 : Dalli를 통해 Memcache 저장소를 사용하는 경우) 모든 클라이언트가 서버에서 세션을 조회하는 데 사용하는 키가있는 쿠키임을 이해합니다. 저장. 나는 아직도 세션 비밀을 정했다. 그러나 나는 그것이 더 이상 무엇을하는지 이해하지 못한다.
큰 난수를 암호화하면 본질적으로 다른 큰 난수가됩니다. 다시 말해서, 정보 (그 단지 난수)에 기인 한 의미가 없다면, 암호화에 대한 보안 이점이 없다. 저장하는 ID에 특정 비트 세트와 같이 일부 정보가 포함되어 있거나 특정 하위 세트의 ID 만 사용되는 경우 암호화가 유용합니다.
세션 ID 길이가 중요합니다. 분명히 ID가 길수록 무차별 적 강제력에 내성이 강합니다. 예상되는 동시 사용자 세션 수 또한 세션 수에 따라 유효한 세션 ID를 찾는 데 필요한 무차별 대입 시도 횟수가 줄어들 기 때문에 하나의 요소입니다. 예를 들어, 두 개의 동시 세션은 ID의 유효 강도를 1 비트 씩 줄입니다 (128 비트 키는 127 비트 키가 하나의 세션에서만 유효하므로 효과적입니다). 1,000,000 개의 동시 세션을 가진 아마존 규모의 웹 사이트는 20 비트의 세션 키 강도를 효과적으로 상실합니다.
무차별 공격으로부터 방어해야하는 경우 미들웨어를 구현하여이를 확인하십시오. 응용 프로그램 고유 문자열과 같은 세션 ID에 정보를 추가하면 무차별 공격을 쉽게 감지 할 수 있습니다 (세션 ID 암호화 필요). 이것은 이 아니며 키 자체의 보안을 강화하며 부적절한 세션 ID가 표시 될 때 앱이 어떤 조치를 취하지 않으면 기본적으로 낭비됩니다.
무엇이든지간에 SSL을 사용하고 쿠키를 https로 설정하십시오. 세션 서버 측 시간 제한을 설정하고 쿠키 만료 및 클라이언트 브라우저의 유언에 의존하지 마십시오.
TL : DR : 세션 ID 저장에 쿠키 만 사용하는 경우 양호한 RNG가 사용되는 경우 암호화가 필요하지 않습니다. SSL을 사용하고 쿠키 secure attribute을 설정하십시오.
좋아, 알았어. 내 세션 ID가 1에서 증가하므로 추측 할 수 없도록 암호를 암호화해야합니다. –
아, 임의의 세션 ID를 사용하고 있다고 가정했습니다. 예, 예측 가능한 세션 쿠키를 확실히 암호화합니다. 가급적 긴 기계 생성 키가 있어야합니다. – Catnapper