일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Observable
- Android 13
- databinding
- RxKotlin
- node
- GCP
- MediaPlayer
- 동영상
- PagingLib
- MediaSession
- paging
- 인앱결제
- SWIFTUI
- mysql
- Android
- MotionLayout
- node.js
- SwiftUI Tutorial
- android13
- google play
- php
- junit
- Reactive
- Animation
- Kotlin
- list
- rx
- Koin
- mvvm
- 테스트 자동화
- Today
- Total
목록보안 (7)
봄날은 갔다. 이제 그 정신으로 공부하자
서비스의 원활한 유지 관리를 위해 회원을 받는 과정에서 우리는 어쩔 수 없이 회원을 식별할 수 있는 개인정보를 수집하게 됩니다. 이러한 개인정보 수집은 개인정보 보호법에 근거하여 필요한 부분만 수집해야 하며 또한 수집한 개인정보는 암호화하여 철저히 관리해야 합니다. 여기서 우리는 문제에 봉착하게 됩니다. 수집한 개인정보를 어떤 방식으로 암호화하여 관리해야 할지는 정확히 잘 모르거든요? 들은 풍월에 의하면 공개키 방식이 보안이 뛰어난데 조금 느린 단점이 있다던데… 근데 해시 함수 암호화는 뭐지??? 등등… 암호화에 대해 검색하다보면 끊임없이 관련된 정보들이 쏟아져 들어오는데… 이제 이러한 정보들 속에서 개인정보를 어떻게 암호화해야할지 난감해지기 시작합니다. 고민할 것 없습니다. 아래 3가지만 정확하게 알면..
이번 글은 지난 글의 후속 글로 패스워드 암호화에 적합한 해시 함수들에 대해 설명합니다. 지난 글에서 결론은 Bcrypt 해시 함수 알고리즘이 패스워드 암호화에 적합하다고 설명하고 끝냈었는데 패스워드 암호화에 적합한 함수는 그것만 있는 것이 아닙니다. 이번 글에서는 그러한 함수들에 대해 설명하고자 합니다. 우선 지난 글에서 설명한 Bcrypt 함수부터 복습해보도록 하겠습니다. Bcrypt Bcrypt는 Blowfish 암호에 기반을 둔 해시 함수로 1999년 USENIX에서 발표되었으며 Bcrypt 함수는 OpenBSD 및 수세 리눅스 등의 일부 리눅스 배포판을 포함한 기타 시스템용 기본 암호 해시 함수 입니다. Bcypt 암호화 해시 알고리즘의 큰 특징은 SHA 계열에서 약점으로 지적된 빠른 연산으로 ..
패스워드 암호화라… 음… 이걸 어떻게 설명해야 좋으려나… 고민 끝에 이렇게 시작해 봅니다. 패스워드 암호화 어떤 것이 좋을까요? 개발을 하다보면 어쩔수 없이 회원의 개인정보를 저장해야 할 상황이 생겨버립니다. 그렇다고 회원 가입을 막을 수도 없고, 개인 정보를 저장하지 않을 수도 없고… 개인정보를 저장하려면 암호화해서 저장해야 하는데 어떤 암호화 알고리즘을 사용해야 하지? 암호화 알고리즘도 완벽하지 않다고 하던데… 내가 사용한 알고리즘이 보안에 취약하면 어떻게하지? 개인정보를 암호화해서 사용하면 서비스가 느려지지 않을까? 모든 개인정보를 다 암호화해야 하나? 고민하다보면 정말 끝없는 의문속에 휩싸이게 됩니다. 그리고 암호화에 대해 공부좀 해볼까 하고 파고 들려고 알아보면 엄청나게 많은 암호화 알고리즘의 ..
개요 앱이 위변조 되는 상황은 두 가지로 볼 수 있습니다. 첫째는 크래커가 내 앱을 디컴파일 후 변조 후 재빌드해서 사용하는 상황이고 둘째는 내 앱을 다운로드 받아 중국의 샤오미 마켓과 같은 다른 마켓에 앱을 등록하는 상황으로 나눌 수 있습니다. 이 번 글에서는 두가지 상황을 방지하는 방법에 대해 설명 하도록 하겠습니다. 첫번째 “크래커가 내 앱을 디컴파일 후 변조 후 재빌드해서 사용하는 상황” 이것을 방지하기 위해 사용되는 것이 앱 서명 키의 Hash key를 사용하는 것 입니다. 앱 서명 키란? 앱을 마켓에 배포하기 위해 배포 빌드를 할 때 앱 서명에 사용되는 키로 크래커가 디컴파일해서 앱을 재빌드 할 경우, 크래커는 내앱의 서명키를 알수 없어, 크래커가 만든 앱은 내가 배포한 앱과는 다른 서명키로 ..
개요 지난번 글에 이어 이번에는 앱이 배포된 뒤 크래커에 의해 디버깅 되는 것을 막는 방법에 대해 설명하도록 하겠습니다. 개발자가 엄청난 노력을 기울여 시큐어 코딩을 하고 코드를 난독화해도 디버깅 툴 연결을 허용한다면 크래커는 적은 노력으로 많은 정보를 획득할 수 있으므로 가능한 디버깅을 막아야 합니다. 크래커가 앱을 크랙킹하기 위해 어떤 것들을 할까요? 앱을 다운로드 받아 디컴파일하고 디버깅툴에 연결해 실행하거나 실행된 앱이 생성한 파일을 추출해 분석할 것 입니다. 그러므로 우리는 이러한 것들을 막을 필요가 있고 막아야 하는 것은 아래 4가지 입니다. 처음 두개는 반드시 막아야하고 뒤에 두가지는 앱에 따라 막는 것을 선택하면 됩니다. - 루팅된 OS 감지 - 디버깅툴 연결 감지 - 개발자 모드 감지 (..
개요 Android 앱은 APK 즉, Application Package로 구성됩니다. 개발자가 play store에 aab(App Bundle)로 앱을 등록해도 실제 사용자가 다운로드 받는 앱은 apk 형식의 파일 입니다. apk 파일은 디컴파일을 통해 소스 형태로 되돌릴 수 있습니다. 즉, 그렇다는 이야기는 악의적인 사용자가 내가 만든 앱을 다운로드 받아 디컴파일을 통해 앱을 빌드 가능한 상태의 소스로 되돌린 후, 수정해 악의적으로 사용하는 것이 가능합니다. 안전한 앱을 만드는 방법 이러한 문제점을 해결하기 위해 앱을 만들고 배포할 때 지켜야하는 몇가지 룰이 있으며 해당 룰만 지킨다면 크랙킹으로부터 안전한 앱을 만들 수 있습니다. 첫번째는 크랙커가 디컴파일을 통해 얻은 소스코드에서 유효한 정보를 얻기..
개인 정보 보호법을 준수하는 서비스를 개발하려면 어떻게 해야 할까요? 답은 간단하지만 그리 쉽지는 않습니다. 우선 우리는 개인 정보 보호법에 대해 알고 그에 맞게 서비스를 개발해야 됩니다. 개인 정보 보호법은 정부에서 친절하게 인터넷에 게시(https://www.law.go.kr/법령/개인정보%20보호법)해 쉽게 찾아 볼 수 있지만 이것을 읽고 이해해 서비스를 개발하는 것은 약간은 지루하고 난해한 일입니다. 그래서 이번 글에서는 개인 정보 보호법 중 서비스 개발에 필요한 부분과 도움이 될만한 정보들을 정리해보았습니다. 벤쳐기업 또는 개인 개발자들이 서비스를 개발하다 흔히 간과하는 부분인 개인정보 보호법 입니다. 이거 생각 외로 중요하고 심각한 부분인데 대부분의 개발자들은 크게 신경 쓰지 않습니다. 나중에..