Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Discussion Topic
비밀번호 리스크 공격을 방지하기 위해 플랫폼마다 비밀번호를 다르게 생성하는 것이 중요한데요. 때문에 Chrome, Safari 등 브라우저에서도 랜덤한 비밀번호를 생성해주도록 서비스를 제공하고 있습니다. 여러 플랫폼 등에 가입할 때마다 keychain등을 활용하는지 혹은 각자만의 암호를 관리하는 방법이 있는지 궁금합니다.
라이브러리가 지속적으로 유지보수되지 않거나 정식 버전이 아닌 경우 사용하지 않은 경험이 있습니다(사실 보안적인 이슈를 고려했다기보단 기능적인 이슈를 우선으로 고려하긴 했습니다..) 그 외에
npm audit등의 커맨드를 적극 활용하여 취약성을 검증하거나 Dependot, Renovate 등을 통해 패키지 버전을 관리하는 서비스를 이용해본 적은 없습니다. 이러한 서비스가 있다는 사실도 모르기도했고 꽤 안일하게 대처하고 있다는 사실을 깨달았습니다. 혹시 취약성을 관리하기 위해 위와 같은 서비스 등을 사용해본 경험이 있는지 궁금합니다.최근 SKT 유심 정보 해킹 사고를 지켜보며 프론트엔드 개발자로서 보안의 중요성을 다시 한번 실감하게 되었습니다. 비록 이번 사건은 네트워크 및 보안 전문가들의 영역이지만 모든 개발 분야에서 탄탄한 보안 기초 지식이 필수적임을 깨닫게 해주었습니다. 프론트엔드 보안 스터디를 진행하면서 실제로 작성하게 될 보안 관련 코드가 크게 없더라도 잠재적인 이슈 등을 고려하면서 개발할 수 있게되어 유익한 스터디였다고 생각합니다!