이 섹션에서는 Bubble 계정을 안전하게 유지하는 방법을 다룹니다.
- Bubble 계정은 여러 가지 이유로 보안에 있어 매우 중요한 부분입니다.
- 이는 앱의 데이터와 사용자 정보를 보호하고 침입자가 앱의 소유권을 생성, 편집, 삭제, 복사 또는 이전하는 것을 방지하는 데 중요합니다.
안전한 계정은 잠재적으로 발생할 수 있는 잘 못된 사용행위를 방지합니다.
보안의 점검은 앱에 추가하되는 잠재적인 보안문제를 회피할 수 있으며 심지어 누군가가 당신의 계정에 접속하여 계정이 제거될 수도 있는 상황을 회피할 수 있다는 점을 명심해야 합니다.
이번 글에서는 계정 보안을 유지하는 방법을 살펴보겠습니다.
Authentication (인증)
1. 비밀번호
비밀번호 및 추가 인증은 앱 수준이 아닌 계정 수준에서 설정됩니다. 즉, 이러한 설정은 모든 앱에 적용됩니다.
강력한 비밀번호 정책은 무단 접속 위험을 줄여줍니다. 강력한 비밀번호 정책을 만들고 유지하려면 다음 지침을 염두에 두십시오
- 고유한 비밀번호 사용: 여러 계정에서 비밀번호를 재사용하지 마세요
- 복잡한 비밀번호 만들기: 비밀번호 길이가 12자 이상이어야 하며 대문자와 소문자, 숫자, 특수 기호를 혼합하여 포함해야 합니다. 이로 인해 공격자가 무차별 대입 방법을 사용하여 비밀번호를 해독하기가 더 어려워집니다.
- 정기적으로 비밀번호 업데이트: 무단 액세스 위험을 최소화하려면 3~6개월마다 비밀번호를 변경하세요. 비밀번호를 업데이트할 때 예측 가능한 패턴을 피하세요
- 비밀번호 관리자 프로그램 사용: 신뢰할 수 있는 비밀번호 관리자 프로그램은 복잡하고 고유한 비밀번호를 생성하고 저장하는 데 도움이 될 수 있습니다. 이렇게 하면 보안을 유지하면서 여러 개의 비밀번호를 기억할 필요가 없습니다.
2. 이중 인증 (2 Factor Authentication: 2FA)
추가 보안 계층을 위해 이중인증을 활성화합니다. 침입자가 당신의 계정에 접근하더라도 위조하기 어려운 추가 확인 단계가 필요합니다.
이중 인증 활성화
- 이중 인증을 활성화하려면 먼저 Growth plan 요금제 이상이 필요합니다.
- 2FA 활성화는 Settings > General에서 세팅합니다.
3. Google Authenticator와 Authy 비교
Google Authenticator와 Authy는 모두 일반 비밀번호 외에 Bubble 계정에 로그인할 때 입력하는 일회용 비밀번호(TOTP)를 제공하는 모바일 앱입니다.
각 설루션에는 몇 가지 장단점이 있으며, 아래 사항은 적합한 설루션을 선택하는 데 도움이 될 수 있습니다.
1) Authy
Authy는 Twilio에서 개발하고 유지관리합니다.
장점:
- 다중 장치 지원: Authy를 사용하면 여러 장치를 동시에 사용할 수 있으므로 휴대폰, 태블릿 또는 데스크톱 간에 더 쉽게 전환할 수 있습니다.
- 클라우드 백업: Authy는 암호화된 클라우드 백업을 활성화하므로 기기를 분실하거나 앱을 다시 설치해야 하는 경우 계정을 더 쉽게 복구할 수 있습니다.
단점:
- 타사 서비스에 의존: Authy의 클라우드 백업 기능은 데이터 저장을 위해 타사 서비스에 의존하기 때문에 일부 사용자에게는 잠재적인 보안 문제가 될 수 있습니다.
2) 구글 Authenticator
Google Authenticator는 Google에서 개발하고 유지관리합니다.
장점:
- 신뢰할 수 있는 회사에서 개발: Google 제품으로서 회사의 보안 전문성과 평판의 이점을 누릴 수 있습니다.
- 로컬 저장: Google Authenticator는 클라우드 백업 기능을 제공하지 않습니다. 이것은 잠재적인 보안 위협이 될 수도 있기 때문입니다.
단점:
- 다중 장치 지원 없음: Google Authenticator는 여러 장치를 동시에 지원하지 않으므로 장치를 바꾸거나 휴대폰을 분실한 경우 불편할 수 있습니다.
- 클라우드 백업 없음: Google Authenticator는 내장된 백업 기능을 제공하지 않으므로 기기를 분실하거나 앱을 다시 설치해야 하는 경우 2FA 계정을 복구하기가 더 어렵습니다.
3) 백업 코드
코드 생성기에 대한 접속 권한을 상실한 경우 계정에 대한 액세스 권한을 잃지 않도록 백업 코드를 생성할 수 있습니다.
- 이는 Authy 또는 Google Authenticator에서 생성된 코드와 동일한 방식으로 계정에 대한 액세스를 제공하는 일회용 고유 문자열입니다.
- 백업 코드는 엄격하게 기밀로 유지되어야 합니다.
- 비밀번호 관리자는 보안을 유지하기 위해 암호화된 데이터베이스에 백업 코드를 저장하는 방법을 제공하는 경우도 있습니다.
4. Bubble이 비밀번호를 저장하고 확인하는 방법
Bubble은 업계 표준 보안 관행을 사용하려 계정 비밀번호를 보호하고 안전하게 유지합니다.
다음은 이러한 기술의 작동 방식에 대한 간략한 설명입니다.
1) Hashing (해싱)
비밀번호를 생성하거나 업데이트할 때 Bubble은 비밀번호의 일반 텍스트 버전을 저장하지 않습니다. 대신, 암호화 Hashing기능을 사용하여 당신의 비밀번호를 고정된 크기의 문자열로 변환한 후 데이터베이스에 저장합니다.
이것이 실제로 의미하는 바는 잠재적인 침입자가 귀하의 비밀번호 문자열을 볼 수 없을 뿐만 아니라 모든 Hashing비밀번호의 문자 수가 동일하므로 길이도 확인할 수 없다는 것입니다.
Hash함수는 단방향으로 설계되었습니다.
- 즉, Hash에서 원래 비밀번호를 리버스 엔지니어링하는 것이 불가능하지는 않더라도 매우 어렵습니다. 로그인하면 Bubble은 당신이 제공한 비밀번호를 Hash 하고 저장된 Hash와 비교합니다.
- Hash가 일치하면 비밀번호가 일치한다고 판단되어 접속 권한이 부여됩니다.
간단히 말해서, Bubble의 엔지니어링 팀조차도 당신의 비밀번호에 접근할 수 없습니다. 오직 자신만이 접근할 수 있습니다.
2) Salting (솔팅)
Hash 된 비밀번호의 보안을 더욱 강화하기 위해 Salting(솔팅)이라는 기술을 사용합니다.
- Salt는 각 사용자에 대해 생성되는 고유한 임의의 문자열입니다.
- 이 Salt는 Hash 되기 전에 사용자의 비밀번호와 결합됩니다.
- 결과적으로 Hash는 Salt와 함께 데이터베이스에 저장됩니다.
- Salting(솔팅)을 사용하면 공격자가 미리 계산된 Hash테이블( 레인보우 테이블이라고 함 )이나 기타 무차별 대입 방법을 사용하여 비밀번호를 해독하는 것이 훨씬 더 어려워집니다.
- 왜냐하면 공격자는 각 고유 Salt에 대해 Hash를 계산해야 하기 때문입니다.