Tag Archives: password

改 Open Distro for Elasticsearch 預設密碼的方式

AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」),應該是目前新架設 Elasticsearch 的首選。

不過裝好後預設有五個帳號,但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (adminkibanaserver),要修改密碼發現得花不少功夫,不知道為什麼要這樣設計 :/

這邊講的是透過 RPM (以及 deb) 的方式的修改方式,如果是 Docker 的方式請參考後面提到在 AWS blog 上的文章:「Change your Admin Passwords in Open Distro for Elasticsearch」。

首先先透過 hash.sh 產生 bcrypt 的 hash,像是這樣 (輸入 password 當密碼):

bash /usr/share/elasticsearch/plugins/opendistro_security/tools/hash.sh
WARNING: JAVA_HOME not set, will use /usr/bin/java
[Password:]
$2y$12$QchkpgY8y/.0TL7wruWq4egBDrlpIaURiBYKoZD50G/twdylgwuhG

然後修改 /usr/share/elasticsearch/plugins/opendistro_security/securityconfig/internal_users.yml 檔案裡面的值,順便改掉 readonly 的部分。

接下來是把這個 internal_users.yml 檔案的設定更新到 Elasticsearch 裡。由於這邊需要讀 /etc/elasticsearch/ 的東西,所以偷懶用 root 跑:

sudo bash /usr/share/elasticsearch/plugins/opendistro_security/tools/securityadmin.sh -cd ../securityconfig/ -icl -nhnv -cacert /etc/elasticsearch/root-ca.pem -cert /etc/elasticsearch/kirk.pem -key /etc/elasticsearch/kirk-key.pem

做完後可能要重跑 Elasticsearch 與 Kibana:

sudo service elasticsearch restart
sudo service kibana restart

或是重開機... 順便測試看看重開後有沒有生效。理論上修改完成後,就是用新的帳號密碼連到 Kibana。

上面的方法是參考了「Default Password Reset」(先找到這篇) 與「change admin password」(後來在 AWS blog 的文章上發現的 GitHub issue 連結) 這邊的資訊。

官方的說明文件則是在寫這篇文章時才找到的,平常搜尋時不太會出現:「Apply configuration changes」。

Facebook 員工爆料內部密碼存了明碼

Krebs on Security 這邊看到的:「Facebook Stored Hundreds of Millions of User Passwords in Plain Text for Years」,Facebook 官方的回應在「Keeping Passwords Secure」這邊。

幾個重點,第一個是範圍,目前已經有看到 2012 的資料都有在內:

The Facebook source said the investigation so far indicates between 200 million and 600 million Facebook users may have had their account passwords stored in plain text and searchable by more than 20,000 Facebook employees. The source said Facebook is still trying to determine how many passwords were exposed and for how long, but so far the inquiry has uncovered archives with plain text user passwords dating back to 2012.

另外的重點是這些資料已經被內部拿來大量搜尋 (喔喔):

My Facebook insider said access logs showed some 2,000 engineers or developers made approximately nine million internal queries for data elements that contained plain text user passwords.

另外是 Legal 與 PR 都已經啟動處理了,對外新聞稿會美化數字,降低傷害:

“The longer we go into this analysis the more comfortable the legal people [at Facebook] are going with the lower bounds” of affected users, the source said. “Right now they’re working on an effort to reduce that number even more by only counting things we have currently in our data warehouse.”

另外也會淡化後續的程序:

Renfro said the company planned to alert affected Facebook users, but that no password resets would be required.

去年的另外一則新聞可以交叉看:「Facebook’s security chief is leaving, and no one’s going to replace him」:

Instead of building out a dedicated security team, Facebook has dissolved it and is instead embedding security engineers within its other divisions. “We are not naming a new CSO, since earlier this year we embedded our security engineers, analysts, investigators, and other specialists in our product and engineering teams to better address the emerging security threats we face,” a Facebook spokesman said in an email. Facebook will “continue to evaluate what kind of structure works best” to protect users’ security, he said.

看起來又要再換一次密碼了... (還好已經習慣用 Password Manager,所以每個站都有不同密碼?)

喔對,另外補充一個概念,當他們說「我們沒有證據有人存取了...」的時候,比較正確的表達應該是「我們沒有稽核這塊... 所以沒有證據」。

最近很紅的密碼...

前幾天在 Twitter 看到,剛剛在 Hacker News Daily 上的整理又看到:

老外在研究的時候發現這個密碼看起來夠長 (12 個字),而且也還算安全 (有英文與數字,看起來無意義),但卻發現被大量重複使用,而不只是單一帳號在用,就很好奇發生這是什麼東西...

對於台灣人來說應該是很熟悉了,這是注音輸入法的「我的密碼」:


出自維基百科的「File:Keyboard layout Zhuyin.svg

非拼音類的輸入法應該都會產生一樣的困惑...

當 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 這家公司的調性了,之後看到他們家的東西要小心。

另外會不會幾個月後之後變成法院認證呢...