S3 Ep95: Slack 누출, Github의 맹공, 포스트 퀀텀 암호화 [오디오 + 텍스트]

원하는 지점으로 건너뛰려면 아래의 음파를 클릭하고 끕니다. 당신은 또한 수 직접 들어 사운드클라우드에서.

더그.  Slack 누출, 못된 GitHub 코드 및 포스트 퀀텀 암호화.

Naked Security 팟캐스트에서 그 모든 것, 그리고 훨씬 더.

[뮤지컬 모뎀]

팟캐스트에 오신 것을 환영합니다.

저는 더그 아모스입니다.

언제나 그렇듯이 폴 더클린이 나와 함께합니다.

폴, 오늘은 어때?

---

오리.  여느 때와 다름없이 아주 굉장해, Doug!

---

더그.  이번 주에 도착하게 되어 매우 기쁩니다. 기술 역사 세그먼트, 왜냐하면…

... 거기에 있었어, 친구!

이번주 11월 XNUMX일...

---

오리.  아뇨!

한푼도 떨어진거 같은데...

---

더그.  연도는 말할 필요도 없어요!

11년 2003월 2000일 – 전 세계가 Windows XNUMX 및 Windows XP 시스템에 영향을 미치는 Blaster 웜에 주목했습니다.

Lovesan 및 MsBlast라고도 하는 Blaster는 버퍼 오버플로를 악용했으며 아마도 다음 메시지로 가장 잘 알려져 있을 것입니다. “빌리 게이츠, 왜 이것을 가능하게 합니까? 돈 버는 일을 멈추고 소프트웨어를 고치십시오.”

무슨 일이야, 폴?

---

오리.  글쎄요, 아마도 우리가 보안을 아주 심각하게 생각하기 전의 시대였을 것입니다.

그리고 다행스럽게도 그런 종류의 버그는 요즘에는 악용하기가 훨씬 더 어렵습니다. 스택 기반 버퍼 오버플로였습니다.

제 기억이 맞다면 Windows의 서버 버전은 이미 스택 보호.

즉, 함수 내부에서 스택을 오버플로하면 함수가 반환되어 손상된 스택으로 손상을 일으키기 전에 나쁜 일이 발생했음을 감지합니다.

따라서 문제가 되는 프로그램을 종료해야 하지만 맬웨어는 실행되지 않습니다.

그러나 그 당시에는 클라이언트 버전의 Windows에는 이러한 보호 기능이 없었습니다.

그리고 내가 기억하는 것처럼, 그것은 당신이 가지고 있는 운영 체제의 버전을 추측해야 했던 초기 맬웨어 중 하나였습니다.

당신은 2000에 있습니까? NT에 있습니까? XP를 사용 중이신가요?

그리고 그것이 잘못되면 시스템의 중요한 부분이 충돌하고 "시스템이 종료될 예정입니다"라는 경고를 받게 됩니다.

---

더그.  하, 그거 기억나!

---

오리.  그래서 많은 사람들에게 당신이 감염에 의해 타격을 받고 있다는 신호인 부수적인 피해가 있었습니다...

...예를 들어 가정 사용자이고 집에 라우터나 방화벽이 없는 경우와 같이 외부에서 발생할 수 있습니다.

그러나 회사 내부에 있는 경우 가장 가능성이 높은 공격은 회사 내부의 다른 사람이 네트워크에 패킷을 뿜어내는 것입니다.

그래서 우리가 몇 년 전에 최근 팟캐스트에서 이야기한 CodeRed 공격과 매우 흡사하게 이 문제의 순전한 규모, 양, 속도가 문제였습니다.

---

더그.  좋아, 약 20년 전의 일이다.

시계를 XNUMX년 전으로 되돌리면 그때 Slack이 누출되기 시작했습니다. 해시된 암호. [웃음]

---

오리.  예, 인기 있는 협업 도구인 Slack…

… 다른 사람에게 작업 공간에 참여하도록 초대 링크를 보낼 수 있는 기능이 있습니다.

그리고 상상해보세요: "링크 생성" 버튼을 클릭하면 내부에 JSON이 포함된 일종의 네트워크 패킷이 생성됩니다.

Zoom 회의 초대를 받은 적이 있다면 날짜와 시간, 초대한 사람, 회의에 사용할 수 있는 URL, 암호 등이 있다는 것을 알 수 있습니다. 물건 - 거기에 꽤 많은 데이터가 있습니다.

일반적으로 원시 데이터를 파헤쳐 그 안에 무엇이 들어 있는지 확인하지 않습니다. 수락/아마도/거절하시겠습니까?”

당신이 말했듯이 XNUMX년 이상 동안 Slack으로 이 작업을 수행했을 때 초대 자체와 엄격하게 관련이 없는 외부 데이터가 초대에 포장되어 있는 것으로 나타났습니다.

따라서 URL도, 이름도, 날짜도, 시간도...

...하지만 *초대하는 사용자의 비밀번호 해시* [웃음]

---

더그.  음.

---

오리.  나는 당신을 괴롭힌다!

---

더그.  안 좋은 소리…

---

오리.  예, 정말 그렇지 않습니까?

나쁜 소식은 그것이 도대체 어떻게 거기에 들어왔느냐는 것입니다.

그리고, 한 번 들어왔을 때 도대체 어떻게 XNUMX년 XNUMX개월 동안 눈치채지 못한 걸까.

사실 네이키드 시큐리티에 대한 기사를 방문해서 보면 전체 URL 기사의 끝에, blahblahblah-for-three-months.

보고서를 처음 읽었을 때 내 마음은 그것을 2017년으로 보고 싶지 않았기 때문입니다! [웃음]

17월 17일부터 17월 XNUMX일까지는 XNUMX이라는 숫자가 많았습니다.

그리고 내 마음은 2017년을 시작 연도로 지웠습니다. "올해의 *2022월에서 XNUMX월*"[XNUMX]로 잘못 읽었습니다.

"와우, *XNUMX개월*이 지났는데도 그들은 눈치채지 못했다."라고 생각했습니다.

그리고 그 기사의 첫 댓글은, “에헴 [기침]. 실제로는 17년 2017월 XNUMX일*이었습니다.”

와우!

그러나 누군가 [17년] 2022월 XNUMX일에 그것을 알아냈고, 그들의 신용에 따르면 Slack은 같은 날 그것을 고쳤습니다.

"오, 골리, 우리가 무슨 생각을 한거야?!"

나쁜 소식입니다.

좋은 소식은 적어도 *해시된* 암호입니다.

그리고 그것들은 단순히 해싱된 것이 아니라 *솔트* 처리되어 고유하게 선택된 사용자별 무작위 데이터를 비밀번호와 혼합합니다.

이에 대한 생각은 두 가지입니다.

첫째, 두 사람이 동일한 비밀번호를 선택하면 동일한 해시를 얻지 못하므로 해시 데이터베이스를 살펴보고 어떤 추론도 할 수 없습니다.

그리고 두 번째, 알려진 입력에 대해 알려진 해시의 사전을 미리 계산할 수 없습니다. *각 솔트*에 대해 각 암호에 대해 별도의 사전을 만들어야 하기 때문입니다.

따라서 해시된 암호를 해독하는 것은 쉬운 일이 아닙니다.

그렇긴 하지만, 전체적인 아이디어는 그것들이 공공 기록의 문제가 되어서는 안 된다는 것입니다.

그들은 해싱되고 * 누출될 경우를 대비하여 소금에 절인 것이지 * 누출될 수 있도록* 하기 위함이 아닙니다.

그래서, Slack의 얼굴에 계란!

Slack은 사용자 200명 중 약 0.5명(XNUMX%)이 영향을 받았다고 말합니다.

그러나 당신이 Slack 사용자라면 XNUMX년 동안 해시된 비밀번호가 유출되고 있다는 사실을 깨닫지 못했다면 아마도 영향을 받은 사람들의 목록을 완전히 열거하지 않았을 것입니다.

따라서 어쨌든 암호를 변경하십시오. 당신도 그렇게 할 수 있습니다.

---

더그.  좋습니다. 또한 다음과 같이 말합니다. 암호 관리자를 사용하지 않는 경우 암호 관리자를 사용하는 것이 좋습니다. 가능하면 2FA를 켜십시오.

---

오리.  나는 당신이 그것을 원한다고 생각했습니다, 더그.

---

더그.  네 저도 그렇습니다!

그런 다음 Slack 또는 이와 유사한 회사라면 다음을 선택하십시오. 평판이 좋은 Salt-hash-and-stretch 알고리즘 비밀번호를 직접 처리할 때.

---

오리.  예.

Slack의 응답에서 가장 큰 문제이자 제가 부족하다고 생각했던 점은 그들이 "걱정하지 마세요. 우리는 비밀번호를 해시했을 뿐만 아니라 솔트 처리했습니다."라고 말했다는 것입니다.

제 조언은 이와 같은 위반에 걸렸다면 솔트 및 해싱에 사용한 알고리즘이나 프로세스, 그리고 이상적으로는 스트레칭이것은 소금에 절인 암호를 한 번만 해시하는 것이 아니라 100,000번 해시하여 사전이나 무차별 대입 공격의 속도를 늦추는 곳입니다.

그리고 어떤 알고리즘을 사용하고 어떤 매개변수와 함께 사용하는지 설명하면.. 예를 들어, PBKDF2, bcrypt, scrypt, Argon2 – 가장 잘 알려진 암호 "salt-hash-stretch" 알고리즘입니다.

실제로 어떤 알고리즘을 사용하고 있는지 진술하면 [A] 더 개방적이며 [B] 문제의 잠재적 피해자에게 이것이 얼마나 위험하다고 생각하는지 스스로 평가할 기회를 주는 것입니다. .

그리고 그런 종류의 개방성은 실제로 많은 도움이 될 수 있습니다.

Slack은 그렇게 하지 않았습니다.

그들은 단지 "오, 그들은 소금에 절여서 해싱되었습니다."라고 말했습니다.

그러나 우리가 모르는 것은 1바이트의 소금을 넣은 다음 SHA-XNUMX로 한 번 해시했는지입니다...

...또는 균열에 대한 저항력이 조금 더 높았습니까?

---

더그.  나쁜 일이라는 주제를 고수하면서 우리는 사람들이 GitHub에 나쁜 물건 주입하기, 무슨 일이 일어나는지 보기 위해, 위험을 노출…

… 그 이야기 중 하나가 더 있습니다.

---

오리.  예, 이제 트위터에 나온 것으로 알려진 누군가가 이렇게 말했습니다. 단지 연구용이었습니다. 블루얼럿에서 눈에 띄는 보고서를 쓰겠다”고 말했다.

그들은 기존의 합법적인 코드를 복사하고 "추가 지침을 위해 집으로 전화", "응답 본문을 실행할 백도어 코드로 해석"과 같은 일부 맬웨어 명령을 의도적으로 삽입하는 것을 기반으로 말 그대로 수천 개의 가짜 GitHub 프로젝트를 만들었습니다. 곧.

따라서 이러한 패키지 중 하나를 설치하면 실제로 해를 끼칠 수 있습니다.

그들에게 합법적인 이름을 부여합니다...

... 분명히 실제 프로젝트의 커밋 기록을 빌려서 "이 파일을 다운로드하십시오. 원하는 거 알잖아!”

진짜?! 연구?? 우리는 이미 이것을 몰랐습니까?!?

이제 "GitHub를 소유한 Microsoft, 사람들이 이런 종류의 항목을 쉽게 업로드할 수 있도록 하는 것은 무엇입니까?"라고 주장할 수 있습니다.

그리고 거기에는 진실이 있습니다.

어쩌면 그들은 처음부터 맬웨어를 차단하는 더 나은 일을 할 수 있습니다.

그러나 "오, 모든 것이 마이크로소프트의 잘못입니다."

“예, 이것은 진정한 연구입니다. 이것은 정말 중요합니다. 우리는 사람들에게 이런 일이 일어날 수 있음을 상기시켜야 합니다.”

[A] 우리는 이미 알고 있습니다. 많은 사람들이 이전에 이 작업을 수행했기 때문에 대단히 감사합니다. 우리는 메시지를 크고 분명하게 받았습니다.

그리고 [B] 이것은 *연구가 아닙니다*.

이는 보고서를 작성할 수 있는 대가로 잠재적인 공격자에게 원격 제어를 제공하는 코드를 다운로드하도록 의도적으로 사람들을 속이려는 것입니다.

그것은 나에게 정당한 연구 동기라기보다 "거대한 변명"처럼 들립니다.

그래서 내가 추천하는 것은 이것이 *연구*라고 생각하고 이와 같은 일을 다시 하기로 결심했다면, 잡히더라도 *많은 동정을 기대하지 말라는 것입니다.

---

더그.  좋아 – 우리는 이것으로 돌아가고 쇼가 끝날 때 독자의 의견을 말할 것이므로 계속 유지하십시오.

하지만 먼저 이야기하자면 신호등, 그리고 사이버 보안과 관련이 있습니다.

---

오리.  아, 네! [웃다]

TLP라는 것이 있습니다. 신호등 프로토콜.

그리고 TLP는 "인간 사이버 보안 연구 프로토콜"이라고 부를 수 있는 것으로서, 다른 사람들에게 보내는 문서에 레이블을 지정하여 그들이 원하는 것(그리고 더 중요하게는 그들이 기대하는 것*)에 대한 힌트를 주는 데 도움이 됩니다. *) 데이터를 처리하지 마십시오.

특히, 얼마나 널리 재배포해야 합니까?

이것이 당신이 세상에 선언할 수 있을 정도로 중요한 일입니까?

아니면 이것이 잠재적으로 위험합니까, 아니면 아직 공개하고 싶지 않은 일부 항목이 잠재적으로 포함되어 있습니까?

그리고 다음과 같이 시작했습니다. TLP:RED, 이것은 "자신에게 보관하십시오"를 의미했습니다. TLP:AMBER, 이는 "이를 긴급히 알아야 한다고 생각하는 회사 내부 또는 고객에게 배포할 수 있음"을 의미했습니다. TLP:GREEN, 즉 "알겠습니다. 사이버 보안 커뮤니티 내에서 널리 퍼질 수 있습니다."

Audiencegain과 TLP:WHITE, 즉 "누구에게나 말할 수 있습니다."

매우 유용하고 매우 간단합니다. RED, AMBER, GREEN... "비밀"과 "기밀"의 차이점과 "기밀"과 "기밀"의 차이점에 대해 걱정하지 않고 전 세계적으로 작동하는 은유입니다. 주변에 많은 법률이 필요합니다.

TLP가 약간 수정되었습니다.

따라서 사이버 보안 연구에 관심이 있다면 해당 사항을 알고 있어야 합니다.

TLP:WHITE 내가 실제로 훨씬 더 나은 용어라고 생각하는 것으로 변경되었습니다. 화이트 우리가 현대 시대에 없이는 할 수 없는 이 모든 불필요한 문화적 함축을 가지고 있습니다.

그래서, TLP:WHITE 이제 막 되었다 TLP:CLEAR, "당신은 이 데이터를 사용하는 것이 분명합니다."라고 말하고 그 의도가 매우 명확하게 명시되어 있기 때문에 제 생각에는 훨씬 더 나은 단어입니다. (죄송합니다, 나는 말장난을 참을 수 없었습니다.)

그리고 추가 레이어가 있습니다(그래서 비유를 약간 망쳤습니다. 이제 *XNUMX* 색상 신호등입니다!).

라는 특별한 레벨이 있습니다. TLP:AMBER+STRICT, 그리고 이것이 의미하는 바는 "이를 회사 내부에서 공유할 수 있습니다."입니다.

그래서 회의에 초대를 받았을 수도 있고 사이버 보안 회사에서 일할 수도 있습니다. 그리고 이것을 프로그래머, IT 팀, 품질 보증 담당자에게 보여줘야 하는 것이 분명합니다. 그래야 조사를 할 수 있습니다. 문제를 해결하거나 해결하십시오.

그러나 TLP:AMBER+STRICT 즉, 조직 내부에 배포할 수는 있지만 *고객이나 고객* 또는 회사 외부 사람들에게 알아야 할 필요가 있다고 생각하는 사람에게 알리지 마십시오.

처음부터 더 긴밀한 커뮤니티 내에서 유지하십시오.

TLP:AMBER, 이전과 마찬가지로 "좋아, 고객에게 말할 필요가 있다고 느끼면 할 수 있습니다."를 의미합니다.

때로는 고객에게 다음과 같이 알리고 싶을 수도 있기 때문에 중요할 수 있습니다. 수정 사항이 도착하기 전에 몇 가지 예방 조치를 취해야 합니다. 하지만 민감한 부분이라 아직 세상에 알리지 말라고 해도 될까요?”

때로는 세상에 너무 일찍 알리는 것이 방어자의 손에 영향을 미치는 것보다 실제로 사기꾼의 손에 더 많은 영향을 미칩니다.

따라서 사이버 보안 응답자라면 다음을 수행하는 것이 좋습니다. https://www.first.org/tlp

---

더그.  그리고 당신은 할 수 있습니다 그것에 대해 더 읽어보세요 우리 사이트에서 네이키드시큐리티.소포스.com.

그리고 다른 가벼운 독서를 찾고 있다면 양자 암호화를 잊어 버리십시오 ... 우리는 다음으로 이동합니다. 포스트 양자 암호화, 폴!

---

오리.  예, 이전에 팟캐스트에서 몇 번 이야기한 적이 있습니다. 그렇죠?

강력하고 신뢰할 수 있는 컴퓨터가 구축될 수 있다고 가정할 때 양자 컴퓨터에 대한 아이디어는 특정 유형의 알고리즘이 오늘날의 최첨단 기술보다 제곱근의 조정까지 가속화될 수 있다는 것입니다. *오늘의 문제 규모의 *로그*.

즉, 2를 취하는 대신²⁵⁶ 특정 해시가 있는 파일을 찾으려고 할 때 ("그냥"!) 2에서 수행할 수 있습니다.¹²⁸ 제곱근인 시도.

분명히 훨씬 빠릅니다.

그러나 이론에 따르면 오늘날 걸리는 시간의 *로그*에서 깨질 수 있다고 느슨하게 말해서 소수의 곱을 인수분해하는 것과 관련된 모든 종류의 문제가 있습니다.

따라서 2를 취하는 대신¹²⁸ [현재 우주의 나이보다 훨씬 더 긴] 균열을 푸는 데 128일이 걸릴 수 있습니다.

또는 "일"을 "분" 등으로 바꿀 수 있습니다.

그리고 불행히도 그 로그 시간 알고리즘( 쇼어의 양자 분해 알고리즘)... 이론적으로 오늘날의 일부 암호화 기술, 특히 공개 키 암호화에 사용되는 기술에 적용될 수 있습니다.

그리고 이러한 양자 컴퓨팅 장치가 앞으로 몇 년 안에 실현 가능하게 된다면, 이 두 가지 특정 공격 클래스에 취약하지 않은 암호화 알고리즘에 대해 지금 준비를 시작해야 할까요?

특히 로그는 잠재적인 공격의 속도를 크게 높여 현재 "아무도 알아낼 수 없을 것"이라고 생각하는 암호화 키가 나중에 공개될 수 있기 때문입니다.

어쨌든 NIST는 국립 표준 기술 연구소 미국에서 은(는) 이러한 마법의 양자 컴퓨터가 나타날 경우 저항할 수 있는 일부 공개, 특허, 잘 조사된 알고리즘을 시도하고 표준화하기 위한 경쟁을 몇 년 동안 운영해 왔습니다.

그리고 최근에 그들은 지금 표준화할 준비가 된 XNUMX가지 알고리즘을 선택했습니다.

그들은 멋진 이름을 가지고 있습니다, Doug, 그래서 나는 그것들을 읽어야 합니다: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON및 SPHINCS+. [웃음]

그래서 그들은 다른 것이 아니라면 멋진 이름을 가지고 있습니다.

그러나 동시에 NIST는 “알고리즘은 XNUMX개뿐입니다. 우리가 할 일은 잠재적인 XNUMX차 후보로 XNUMX명을 더 뽑고 그 중 하나라도 통과해야 하는지 알아보는 것입니다.”

따라서 현재 XNUMX개의 표준화된 알고리즘이 있고 미래에 표준화될 수 있는 XNUMX개의 알고리즘이 있습니다.

또는 5년 2022월 XNUMX일에 XNUMX개가 *있었고* 그 중 하나는 SIKE, 짧은 초특이 동질성 키 캡슐화.

(초특이 동질성을 설명하려면 여러 팟캐스트가 필요하므로 신경쓰지 않겠습니다. [웃음])

그러나 불행히도 표준화될 가능성을 안고 매달려 있던 이 제품은 공개된 지 최소 XNUMX년이 넘었음에도 불구하고 돌이킬 수 없을 정도로 망가진 것처럼 보인다.

그래서 다행스럽게도 표준화되기 직전에 두 벨기에 암호학자가 "그거 알아? 평균적인 CPU에서 단 하나의 코어를 사용하여 약 XNUMX시간이 소요되는 계산을 사용하여 이 문제를 해결할 수 있다고 생각합니다.”

---

더그.  표준화하고 야생에서 꺼내는 것보다 지금 그것을 찾는 것이 더 나을 것 같습니까?

---

오리.  과연!

이미 표준화된 알고리즘 중 하나였다면 표준을 폐지하고 새 표준을 제시해야 하지 않을까요?

이게 XNUMX년 동안 주목받지 못한 게 이상한 것 같다.

그러나 그것이 대중 조사의 전체 아이디어라고 생각합니다. 누군가가 필요한 균열을 언제 막 칠지, 또는 알고리즘이 원래 생각했던 것만큼 강력하지 않다는 것을 침입하고 증명하기 위해 사용할 수 있는 작은 쐐기를 사용할 수 있는지 알 수 없습니다.

자신의 암호를 짜는 것을 *언제라도* 생각했다면…

---

더그.  [웃음] 안 했어요!

---

오리.  ..네이키드 시큐리티(Naked Security) 팟캐스트에서 N번 말했지만 “하지마!”

이것은 진정한 전문가가 XNUMX년 동안 글로벌 경쟁에서 공개 조사 대상이 되는 알고리즘을 내놓았을 때에도 이것이 여전히 상당히 나쁜 것으로 판명된 결함을 폭로할 충분한 시간을 제공하지 않는다는 것을 궁극적으로 상기시켜야 합니다.

따라서 이것은 확실히 좋지 않습니다. SIKE 연산.

그리고 누가 그것이 철회 될 것인지 누가 압니까?

---

더그.  우리는 그것을 주시할 것입니다.

그리고 이번 주 쇼의 해가 천천히 지기 때문에 이전에 논의한 GitHub 이야기에 대한 독자 중 한 명의 이야기를 들을 시간입니다.

강도질하다 쓰기:

“댓글에 분필과 치즈가 있는데, 말하기 싫지만 진정으로 논쟁의 양면을 볼 수 있습니다. 위험하고 번거롭고 시간 낭비이며 자원을 소모합니까? 예, 물론입니다. 범죄 생각이 많은 유형이 할 일입니까? 예, 그렇습니다. GitHub 또는 이와 관련된 다른 코드 저장소 시스템을 사용하는 모든 사람에게 인터넷을 안전하게 여행하려면 건전한 정도의 냉소주의와 편집증이 필요하다는 것을 상기시켜 줍니까? 예. 시스템 관리자로서 내 일부는 당면한 위험에 대한 노출에 박수를 보내고 싶습니다. 여러 개발자의 시스템 관리자로서 저는 이제 모든 사람들이 최근에 의심스러운 항목에 대한 풀을 샅샅이 조사했는지 확인해야 합니다.”

---

오리.  네, RobB님, 그 의견에 감사드립니다. 논쟁의 양쪽 측면을 모두 보는 것이 중요하다고 생각하기 때문입니다.

'도대체 이게 무슨 문제야? 대단해!”

한 사람이 말했습니다. “아니요, 사실 이 펜 테스트는 훌륭하고 유용합니다. 실제 공격자에게서 추악한 머리를 기르는 대신 지금이 노출되어 기쁩니다.”

이에 대한 내 대답은 "글쎄, 이것은 사실은 *공격이다."입니다.

나중에 누군가가 나와서 "아, 아니, 아니. 피해가 없습니다! 솔직히 장난 아니었어요.”

나는 당신이 그 변명을 살 의무가 있다고 생각하지 않습니다!

그러나 어쨌든 이것은 침투 테스트가 아닙니다.

내 대답은 아주 간단하게 다음과 같았습니다. "책임 있는 침투 테스터는 [A] 명시적 허가를 받은 후에만 행동하고 [B] 사전에 명시적으로 동의한 행동 제한 내에서만 행동합니다."

당신은 당신 자신의 규칙을 만들지 않으며 우리는 이전에 이것을 논의했습니다.

그래서 다른 댓글 작성자가 말했듯이 제가 가장 좋아하는 댓글입니다... 이커브가 말했다, “누군가가 집집을 돌아다니며 창문을 부수고 도어록이 실제로 얼마나 비효율적인지 보여줘야 한다고 생각합니다. 연체입니다. 누가 이것 좀 밟아주세요.”

그리고 그것이 풍자라는 것을 깨닫지 못한 경우를 대비하여 그는 말합니다. "아니!"

---

오리.  좋은 알림이라는 생각이 들었고 GitHub 사용자라면 생산자와 소비자 모두에게 할 수 있는 일이 있다는 생각이 듭니다.

의견과 기사에 나열합니다.

예를 들어, 모든 커밋에 디지털 서명을 넣어 변경 사항이 사용자에게 있음을 분명히 하고 일종의 추적 가능성이 있습니다.

그리고 검색을 했고 그것이 올바른 프로젝트인 것처럼 보였다고 해서 맹목적으로 물건을 소비하지 마십시오.

그렇습니다, 우리는 모두 이것으로부터 배울 수 있습니다. 그러나 이것이 실제로 우리를 가르치는 것으로 간주됩니까, 아니면 그것이 우리가 어쨌든 배워야 하는 것입니까?

나는 이것이 가르치는 것이 *아닙니다*라고 생각합니다.

연구로 간주할 수 있는 *충분히 높은 수준*이 아닙니다.

---

더그.  이 기사에 대한 훌륭한 토론과 함께 보내주셔서 감사합니다. Rob.

제출하고 싶은 흥미로운 이야기, 의견 또는 질문이 있으면 팟캐스트에서 읽고 싶습니다.

당신은 이메일을 보낼 수 있습니다 tips@sophos.com; 우리 기사 중 하나에 댓글을 달 수 있습니다. 또는 소셜에서 우리를 공격할 수 있습니다. @NakedSecurity.

그것이 오늘의 쇼입니다. 들어주셔서 대단히 감사합니다.

Paul Ducklin의 경우 Doug Aamoth라고 합니다. 다음 시간까지...

---

양자 모두.  보안 유지!

[뮤지컬 모뎀]