Security ko KR

보안

암호화(Encryption)

ASF는 현재 ECryptoMethod의 정의로서 다음과 같은 암호화 방식을 지원합니다:

값	이름
0	평문(PlainText)
1	고급 암호화 표준(AES)
2	ProtectedDataForCurrentUser
3	EnvironmentVariable
4	파일

정확한 설명과 각 방식의 비교는 아래에서 확인하실 수 있습니다.

설치

예를 들어 SteamPassword용 암호화된 비밀번호를 생성하려면, 선택한 암호화 방식과 원래의 평문 비밀번호를 사용해 encrypt **명령어**를 실행해야 합니다. 이후, 얻은 암호화된 문자열을 SteamPassword 봇 설정 속성 값으로 입력하고, 마지막으로 PasswordFormat을 선택한 암호화 방식에 맞는 값으로 변경하세요. 일부 형식은 encrypt 명령어가 필요하지 않습니다. 예를 들어 EnvironmentVariable이나 File은 적절한 경로만 입력하면 됩니다.

---

평문(PlainText)

이는 비밀번호를 저장하는 가장 단순하고 가장 안전하지 않은 방식으로, ECryptoMethod의 0으로 정의됩니다. ASF는 이 문자열이 평문(plain text) - 즉 비밀번호 원문 그대로 - 이기를 기대합니다. 이는 사용하기 가장 쉽고, 모든 설정과 100% 호환되므로 기본(default) 저장 방식이지만, 안전한 저장을 위해서는 전혀 안전하지 않습니다.

---

고급 암호화 표준(AES)

오늘날 기준으로 안전하다고 간주되는 AES 방식의 비밀번호 저장은 ECryptoMethod의 1로 정의됩니다. ASF는 이 문자열이 base64로 인코딩된 문자열이며, 이를 변환하면 AES로 암호화된 바이트 배열이 되고, 이후 포함된 **초기화 벡터(initialization vector)**와 ASF 암호화 키를 사용해 복호화되어야 한다고 기대합니다.

위 방식은 공격자가 비밀번호의 암호화 및 복호화에 사용되는 ASF 암호화 키를 알지 못하는 한 보안을 보장합니다. ASF는 --cryptkey 명령줄 인자 를 통해 최대한의 보안을 위해서 특정 키의 사용을 허락합니다. 이를 생략하기로 했다면 ASF는 알려져있고 어플리케이션에 하드코딩된 자체 키를 사용할 것입니다. 이는 누구나 ASF 암호화를 뒤집어서 복호화된 암호를 얻을 수 있다는 뜻힙니다. 여전히 약간 노력이 필요하고 하기 쉽지는 않지만, 가능한 일입니다. 이것이 AES 암호화는 비밀리에 보관하고 있는 자신만의 --cryptkey를 사용해야 하는 이유입니다. ASF에서 사용하는 AES 방법은 만족스러운 보안성을 제공하고 평문(PlainText)의 단순함과 ProtectedDataForCurrentUser의 복잡성 간의 균형점입니다. 하지만 사용자의 --cryptkey와 함께 사용하는 것을 강력하게 권장합니다.

(길고 사용자 지정된) --cryptkey를 제대로 사용하면, 매우 높은 수준의 안전한 저장 보안을 보장합니다.

---

ProtectedDataForCurrentUser

오늘날 기준으로 안전하다고 간주되는 DPAPI 방식의 비밀번호 저장은 ECryptoMethod의 2로 정의됩니다. 이 방법의 주된 장점은 동시에 주된 단점입니다. AES 등 암호화 키를 사용하는 대신 현재 로그인 된 사용자의 로그인 자격을 이용하여 데이터를 암호화합니다. 즉, 오직 암호화된 기기에서만, 또한 오직 암호화한 사용자만 데이터를 복호화할 수 있습니다.

이 방식을 사용하면, 이 방법으로 암호화된 SteamPassword가 포함된 전체 Bot.json 파일을 다른 사람에게 보내더라도, 해당 사용자는 여러분의 PC에 직접 접근하지 않는 한 비밀번호를 복호화할 수 없습니다. 이는 뛰어난 보안 수단이지만, 동시에 호환성이 가장 낮다는 큰 단점이 있습니다. 이 방식으로 암호화된 비밀번호는 다른 사용자뿐만 아니라 다른 기기와도 호환되지 않으며, 예를 들어 여러분이 운영체제를 재설치하는 경우 본인 기기에서조차 호환되지 않습니다. 이는 본인 기기 외의 다른 기기에서 설정 파일에 접근할 필요가 없고, 기기 간 호환성도 필요하지 않은 경우에 권장되는 방식입니다.

이 옵션은 현재로서는 Windows OS를 실행하는 기기에서만 사용할 수 있다는 점을 유의하시기 바랍니다.

---

EnvironmentVariable

메모리 기반 저장 방식은 ECryptoMethod의 3으로 정의됩니다. ASF는 비밀번호 필드에 지정된 이름을 가진 환경 변수(예: SteamPassword)에서 비밀번호를 읽어옵니다. 예를 들어, SteamPassword를 ASF_PASSWORD_MYACCOUNT로, PasswordFormat을 3으로 설정하면, ASF는 ${ASF_PASSWORD_MYACCOUNT} 환경 변수를 평가하여 해당 값을 계정 비밀번호로 사용하게 됩니다.

ASF 프로세스의 환경 변수가 권한 없는 사용자에게 노출되지 않도록 반드시 확인하세요. 그렇지 않으면 이 방식을 사용하는 목적 자체가 무의미해집니다.

---

파일

(ASF 설정 디렉터리 외부일 수도 있는) 파일 기반 저장 방식은 ECryptoMethod의 4로 정의됩니다. ASF는 비밀번호 필드에 지정된 파일 경로(예: SteamPassword)에서 비밀번호를 읽어옵니다. 지정된 경로는 절대 경로일 수도 있고, ASF의 "홈" 위치(config 디렉터리가 있는 폴더) 기준의 상대 경로일 수도 있습니다. 이때 --path **명령줄 인수**를 고려합니다. 이 방식은 예를 들어 이런 파일을 사용할 수 있도록 생성해주는 **Docker secrets**와 함께 사용할 수 있지만, Docker 외부에서도 사용자가 직접 적절한 파일을 생성하기만 하면 사용할 수 있습니다. 예를 들어, SteamPassword를 /etc/secrets/MyAccount.pass로, PasswordFormat을 4로 설정하면, ASF는 /etc/secrets/MyAccount.pass 파일에 기록된 내용을 읽어 계정 비밀번호로 사용하게 됩니다.

비밀번호가 담긴 파일이 권한 없는 사용자에게 읽히지 않도록 반드시 확인하세요. 그렇지 않으면 이 방식을 사용하는 목적 자체가 무의미해집니다.

---

암호화 권장 사항

호환성이 문제가 되지 않고, ProtectedDataForCurrentUser 방식의 동작 방식이 여러분에게 문제없다면, 이것이 ASF에서 비밀번호를 저장하는 권장 방식입니다. 최고의 보안성과 편의성을 제공합니다. AES 방법은 원하는 어느 기기에서나 환경설정을 사용하길 원하는 사람들에게 좋은 선택입니다. 그리고 평문은 누구나 JSON 환경설정 파일을 들여다 볼 수 있다는 것을 개의치 않는다면 가장 단순한 암호 저장방식입니다.

다만, 공격자가 여러분의 PC에 접근할 수 있다면 모든 암호화 방식은 안전하지 않은 것으로 간주된다는 점을 유의하시기 바랍니다. ASF는 암호화된 비밀번호를 복호화할 수 있어야 하며, 만약 여러분의 기기에서 실행 중인 프로그램이 이를 수행할 수 있다면, 같은 기기에서 실행되는 다른 어떤 프로그램도 마찬가지로 이를 수행할 수 있습니다. ProtectedDataForCurrentUser는 심지어 같은 PC를 이용하는 다른 사용자도 복호화를 할 수 없을만큼 가장 안전하지만, 누군가가 로그인 자격과 기기정보, ASF 환경설정 파일을 숨친다면 여전히 복호화는 가능합니다.

고급 설정을 위해서는 EnvironmentVariable과 File을 활용할 수 있습니다. 이 방식들은 활용도가 제한적입니다. EnvironmentVariable은 사용자 지정 솔루션을 통해 비밀번호를 얻어와 오직 메모리에만 저장하고 싶은 경우 좋은 선택이며, File은 예를 들어 **Docker secrets**와 함께 사용하기 좋습니다. 다만 이 두 방식 모두 암호화되어 있지 않으므로, 결국 위험을 ASF 설정 파일에서 여러분이 선택한 두 방식 중 하나로 옮기는 것일 뿐입니다.

위에서 설명한 암호화 방식 외에도, 비밀번호를 아예 지정하지 않는 것도 가능합니다. 예를 들어 SteamPassword를 빈 문자열이나 null 값으로 설정하는 방식입니다. 이 경우 ASF는 필요할 때 비밀번호를 물어보며, 실행 중인 프로세스의 메모리에만 보관하고 어디에도 저장하지 않습니다. 프로세스를 종료하면 그 값도 사라집니다. 비밀번호를 다루는 방식 중 가장 안전하지만(어디에도 저장되지 않으므로), 동시에 가장 번거로운 방식이기도 합니다. ASF를 실행할 때마다(필요할 때) 비밀번호를 수동으로 입력해야 하기 때문입니다. 이것이 문제가 되지 않는다면, 보안 측면에서 최선의 선택입니다. 애초에 존재하지 않는 것은 유출될 수도 없기 때문입니다.

---

복호화

ASF는 이미 암호화된 암호를 복호화하는 어떠한 방법도 지원하지 않습니다. 복호화 방법은 프로세스 안에서 데이터에 접근하기 위해 내부적으로만 사용됩니다. ProtectedDataForCurrentUser를 사용하다가 예를 들어 ASF를 다른 기기로 옮기는 등의 이유로 암호화 절차를 되돌리고 싶다면, 새 환경에서 처음부터 절차를 다시 반복하기만 하면 됩니다.

---

해싱(Hashing)

ASF는 현재 EHashingMethod의 정의로서 다음과 같은 해싱 방식을 지원합니다:

값	이름
0	평문(PlainText)
1	SCrypt
2	Pbkdf2

정확한 설명과 각 방식의 비교는 아래에서 확인하실 수 있습니다.

설치

예를 들어 IPCPassword용 해시를 생성하려면, 선택한 해싱 방식과 원래의 평문 비밀번호를 사용해 hash **명령어**를 실행해야 합니다. 이후, 얻은 해시 문자열을 IPCPassword ASF 설정 속성 값으로 입력하고, 마지막으로 IPCPasswordFormat을 선택한 해싱 방식에 맞는 값으로 변경하세요.

---

평문(PlainText)

이는 비밀번호를 해싱하는 가장 단순하고 가장 안전하지 않은 방식으로, EHashingMethod의 0으로 정의됩니다. ASF는 원본 입력값과 일치하는 해시를 생성합니다. 이는 사용하기 가장 쉽고, 모든 설정과 100% 호환되므로 비밀 정보를 저장하는 기본(default) 방식이지만, 안전한 저장을 위해서는 전혀 안전하지 않습니다.

---

SCrypt

오늘날 기준으로 안전하다고 간주되는 SCrypt 방식의 비밀번호 해싱은 EHashingMethod의 1로 정의됩니다. ASF는 SCrypt 구현을 사용하며, 8 블록, 8192 반복(iteration), 32 해시 길이를 사용하고 암호화 키를 솔트(salt)로 사용해 바이트 배열을 생성합니다. 이렇게 생성된 바이트는 이후 base64 문자열로 인코딩됩니다.

ASF는 이 방식을 위한 솔트를 --cryptkey **명령줄 인수**를 통해 지정할 수 있게 해주며, 최대한의 보안을 위해서는 이를 사용하는 것을 권장합니다. 이를 생략하기로 하면, ASF는 애플리케이션에 알려져 있고 하드코딩된 자체 키를 사용하게 되며, 이는 해싱의 보안성을 떨어뜨립니다.

제대로 사용하면(사용자 지정 솔트, 긴 비밀번호), 안전한 저장을 위한 매우 높은 수준의 보안을 보장합니다.

---

Pbkdf2

오늘날 기준으로는 약하다고 간주되는 Pbkdf2 방식의 비밀번호 해싱은 EHashingMethod의 2로 정의됩니다. ASF는 Pbkdf2 구현을 사용하며, 10000 반복(iteration), 32 해시 길이, 암호화 키를 솔트로 사용하고, HMAC 알고리즘으로는 SHA-256을 사용합니다. 이렇게 생성된 바이트는 이후 base64 문자열로 인코딩됩니다.

ASF는 이 방식을 위한 솔트를 --cryptkey **명령줄 인수**를 통해 지정할 수 있게 해주며, 최대한의 보안을 위해서는 이를 사용하는 것을 권장합니다. 이를 생략하기로 하면, ASF는 애플리케이션에 알려져 있고 하드코딩된 자체 키를 사용하게 되며, 이는 해싱의 보안성을 떨어뜨립니다.

---

해싱 권장 사항

IPCPassword와 같은 일부 비밀 정보를 저장할 때 해싱 방식을 사용하고 싶다면, 사용자 지정 솔트와 함께 SCrypt를 사용하는 것을 권장합니다. 이는 무차별 대입 공격(brute-forcing)에 대해 매우 준수한 보안성을 제공합니다.

Pbkdf2는 오직 호환성을 위해서만 제공됩니다. 주된 이유는, Steam 플랫폼 전반의 다른 사용 사례(예: 부모 제한 PIN)를 위해 이미 이에 대한 작동하는(그리고 필요한) 구현을 보유하고 있기 때문입니다. 여전히 안전한 것으로 간주되지만, SCrypt와 같은 대안에 비해서는 약한 편입니다.