Home » Posts tagged "password"

當 credential 外洩時的處理方式...

昨天講到 Udacity 把 credential 放到 git repository 裡的方式 (參考「Udacity 管理 credential 的方式...」這篇),結果就看到另外一篇講當外洩時降低傷害的文章:「Leak Mitigation Checklist」。

裡面講的方法沒什麼特別的 (倒是花了不少篇幅在介紹各家的 credential 要怎麼重生),畢竟這是一份 checklist,只是要確保最低標準的步驟都應該要確認有做。


Udacity 管理 credential 的方式...

看到 Udacity 管 credential 的方式,可以用「我就是想把這些東西放到 Git 裡面管理啦」來解釋:「Three Simple Rules for Putting Secrets into Git」。

看了一下 Udacity 的架構,從 catalog-api.udacity.com 看起來應該是放在 AWSus-west-2 上?那麼不考慮使用 AWS 的 KMS 是什麼?或是退一步來說,連自架的 Vault 也不考慮的原因又是什麼?下面的 response 好像沒什麼人提出問題... 在不知道前提的情境下,選擇這樣的方法其實有點怪,2012 年成立的公司有這麼重的包袱嗎?

先看看就好 XD

CA/Browser Forum 上的會議記錄:關於密碼與 2FA 的強制要求

CA/Browser Forum 會定時將會議記錄與最後的結論公開放在網站上,有時候有些資訊還蠻有趣的。像是前幾天在「Ballot 221 - Two-Factor Authentication and Password Improvements - CAB Forum」這邊看到 CA/Browser Forum 的成員對密碼與 2FA 提出了修正提案,其中瀏覽器端只有 Microsoft 參與投票,但是被否決了...


第一個是提案提到了 NSANIST 800-63B Appendix A,這個單位不太受歡迎啊...

第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼,而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案),像是早期的 U2F 以及今年定案的 WebAuthn


Twitter 密碼中槍...

Twitter 發了公告請大家改密碼:「Keeping your account secure」。不只是 Twitter 自家的密碼,如果你有重複使用同一組密碼,也建議一起修改:

Out of an abundance of caution, we ask that you consider changing your password on all services where you’ve used this password.

雖然使用 bcrypt,但因為透過 log 記錄下了未加密的密碼,所以就中槍了:

We mask passwords through a process called hashing using a function known as bcrypt, which replaces the actual password with a random set of numbers and letters that are stored in Twitter’s system. This allows our systems to validate your account credentials without revealing your password. This is an industry standard.

Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.

這時候就要再推 Password manager 這種東西了,在每個站台都使用完全不同的密碼,可以降低這類問題帶來的衝擊...

Windows 10 自動安裝 Keeper 產生安全漏洞,然後 Keeper 決定告記者...

Ars Technica 報導了 Windows 10 自動安裝了 Keeper 這個密碼管理程式,然後這個管理程式被 Tavis Ormandy 發現有安全漏洞,可以讓惡意網站直接存取密碼 (參考「keeper: privileged ui injected into pages (again)」):「For 8 days Windows bundled a password manager with a critical plugin flaw」。

發現漏洞的作者在 16 個月前有抓到 Keeper 的漏洞 (參考「Keeper: Trusted UI is injected into untrusted webpage」),於是他就拿同樣的方法打一打,結果就爆了:

I assume this is some bundling deal with Microsoft. I've heard of Keeper, I remember filing a bug a while ago about how they were injecting privileged UI into pages ( issue 917 ). I checked and, they're doing the same thing again with this version. I think I'm being generous considering this a new issue that qualifies for a ninety day disclosure, as I literally just changed the selectors and the same attack works.

漏洞後來被修正了,但是 Keeper 也對 Ars Technica 的記者提告:「Security firm Keeper sues news reporter over vulnerability story」。

Keeper said in its lawsuit that Goodin and his employer, tech site Ars Technica, also named as defendant, "made false and misleading statements about the Keeper software application suggesting that it had a 16-month old bug that allowed sites to steal user passwords."

這樣就清楚知道 Keeper 這家公司的調性了,之後看到他們家的東西要小心。


Password Spray:用同個密碼暴力打所有的 username

在「Simplifying Password Spraying」這篇看到,原來這個叫做 Password Spray...

To give a little background, traditional brute force attacks of one username with multiple passwords don't work very well against Windows services. This is because they employ lockout functionality after a set number of login attempts. A Password Spray circumvents the lockout functionality by trying only a few of the most common passwords against multiple user accounts, trying to identify that one person who is using 'Password1' or 'Summer2017'.


Hashcat 的 Rule

在「基于统计学的Hashcat密码生成规则:Hob0Rules」這邊看到的專案,雖然有點久了:「Password cracking rules for Hashcat based on statistics and industry patterns」。

裡面有兩個 rule file,hob064.rule 比較簡單:

hob064 This ruleset contains 64 of the most frequent password patterns used to crack passwords. Need a hash cracked quickly to move on to more testing? Use this list.

d3adhob0.rule 比較多,也比較完整:

d3adhob0 This ruleset is much more extensive and utilizes many common password structure ideas seen across every industry. Looking to spend several hours to crack many more hashes? Use this list.

記錄起來以後應該用的到 XD

Imgur 也漏資料了... (帳號與密碼)

Imgur 官方發佈公告說明他們發現資料洩漏了:「Notice of Data Breach」,資料的洩漏是發生在 2014 年,包括了帳號與密碼:

Early morning on November 24th, we confirmed that approximately 1.7 million Imgur user accounts were compromised in 2014. The compromised account information included only email addresses and passwords. Imgur has never asked for real names, addresses, phone numbers, or other personally-identifying information (“PII”), so the information that was compromised did NOT include such PII.

然後 2014 年用的是 SHA-256

We have always encrypted your password in our database, but it may have been cracked with brute force due to an older hashing algorithm (SHA-256) that was used at the time. We updated our algorithm to the new bcrypt algorithm last year.

以單台八張 GTX 1080hashcat 的速度來看 (出自「8x Nvidia GTX 1080 Hashcat Benchmarks」),是 23GH/z 左右:

Hashtype: SHA256

Speed.Dev.#1.: 2865.2 MH/s (96.18ms)
Speed.Dev.#2.: 2839.8 MH/s (96.65ms)
Speed.Dev.#3.: 2879.5 MH/s (97.14ms)
Speed.Dev.#4.: 2870.6 MH/s (96.32ms)
Speed.Dev.#5.: 2894.2 MH/s (96.64ms)
Speed.Dev.#6.: 2857.7 MH/s (96.78ms)
Speed.Dev.#7.: 2899.3 MH/s (96.46ms)
Speed.Dev.#8.: 2905.7 MH/s (96.26ms)
Speed.Dev.#*.: 23012.1 MH/s

這對於鍵盤可以打出的所有字元來計算 (95 chars),八個字的密碼只要 3.33 天就可以跑完;如果只考慮英文數字 (62 chars),九個字的密碼只要 6.81 天。

這些還不是最新的 GPU,而且是單機計算,對於現在的攻擊應該會用 ASIC,可以考慮多三到四個數量級的數度在算 (看財力才會知道買多少機器)。

不過 Imgur 的帳號主要是參與討論 (因為不用帳號密碼也可以上傳圖片),一般比較不會在上面註冊... 真的有註冊的因為沒有其他個資,主要是怕共用密碼的問題。如果有用 password manager 應該也還好。

各家 Session Replay 服務對個資的處理

Session Replay 指的是重播將使用者的行為錄下來重播,市面上有很多這樣的服務,像是 User Replay 或是 SessionCam

這篇文章就是在討論這些服務在處理個資時的方式,像是信用卡卡號的內容,或是密碼的內容,這些不應該被記錄下來的資料是怎麼被處理的:「No boundaries: Exfiltration of personal data by session-replay scripts」,主要的重點在這張圖:

後面有提到目前防禦的情況,看起來目前用 adblock 類的軟體可以擋掉一些服務,但不是全部的都在列表裡。而 DNT 則是裝飾品沒人鳥過:

Two commonly used ad-blocking lists EasyList and EasyPrivacy do not block FullStory, Smartlook, or UserReplay scripts. EasyPrivacy has filter rules that block Yandex, Hotjar, ClickTale and SessionCam.

At least one of the five companies we studied (UserReplay) allows publishers to disable data collection from users who have Do Not Track (DNT) set in their browsers. We scanned the configuration settings of the Alexa top 1 million publishers using UserReplay on their homepages, and found that none of them chose to honor the DNT signal.

Improving user experience is a critical task for publishers. However it shouldn’t come at the expense of user privacy.