Raspberry Pi OS 改掉預設的帳號 pi
與密碼 raspberry
這個 security hole 了:「An update to Raspberry Pi OS Bullseye」。
取而代之的是在安裝時要求使用者建立帳號密碼:

如果是 terminal-based 的會是這樣:

之前裝完都要自己用 vipw
改掉,然後接著修改 /etc/group
... (沒有習慣用 vigr
)
幹壞事是進步最大的原動力
Raspberry Pi OS 改掉預設的帳號 pi
與密碼 raspberry
這個 security hole 了:「An update to Raspberry Pi OS Bullseye」。
取而代之的是在安裝時要求使用者建立帳號密碼:
如果是 terminal-based 的會是這樣:
之前裝完都要自己用 vipw
改掉,然後接著修改 /etc/group
... (沒有習慣用 vigr
)
看到「Setting Up Git Identities」這篇,裡面提到的方法可以解決 Git 裡有多個身份時常見的用錯身份的問題...
個人的 Git repository 會希望用自己的 email address,而公司的 Git repository 則是希望用公司的 email address,但 Git 預設會使用 username 與 hostname 組一個出來,所以常常是推到公司的機器上後才發現 Git repository 沒設定公司的 email address...
上面提到的文章就是關掉 Git 預設會組合的行為,於是就會記得要設定了:
git config --global user.useConfigOnly true
然後記得要把全域設定裡的 name
與 email
拔掉,另外有些人可能會掛上 signingkey
也一起拔掉:
git config --global --unset user.name git config --global --unset user.email git config --global --unset user.signingkey
這樣當沒設定時想要 git commit
,就會被擋下來要求你提供,就能避免把自己的 email address 混在公司的 Git repository 裡面了...
看到 Twitter 要清沒有在用的帳號的消息:「Twitter will remove inactive accounts and free up usernames in December」,官方的「Inactive account policy」裡面也可以看到。
看起來定義上是六個月沒有動,官方就可以當作 inactive account 處理:
We encourage people to actively log in and use Twitter when they register an account. To keep your account active, be sure to log in and Tweet at least every 6 months. Accounts may be permanently removed due to prolonged inactivity.
讓我想到先前 arashi_5_official
帳號的取名原因 XDDD
另外不知道會怎麼處理權限上的配套措施,像是有不少網站支援 Twitter 帳號登入,如果被其他人拿到後代表有機會取得其他非 Twitter 系統的權限...
AWS 弄出來的 Open Distro for Elasticsearch 因為內建了安全性的功能 (參考「AWS 對 Elastic Stack 實作免費的開源版本 Open Distro for Elasticsearch」),應該是目前新架設 Elasticsearch 的首選。
不過裝好後預設有五個帳號,但從 Open Distro 的 Kibana 介面無法修改改其中兩個使用者的密碼 (admin
與 kibanaserver
),要修改密碼發現得花不少功夫,不知道為什麼要這樣設計 :/
這邊講的是透過 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」。
好像跟當初外面傳言的不太一樣... Anyway,Twitter 宣佈放寬 140 字限制:「Coming soon: express even more in 140 characters」。
這個限制的解除一直都有傳言,不過最後出來的結果跟預期的好像不太一樣,主要是三種用法將不計算在 140 字內。分別是 reply 時的 @username、貼圖貼影片時的 url、引用 tweet 時被引用的文字。
所以並不是完全放寬 140 字限制,只是把某些計算方式放寬...
在「Another Day, Another Hack: 117 Million LinkedIn Emails And Passwords」這邊看到 LinkedIn 在 2012 年的帳號密碼外洩情況比想像中嚴重許多,當時大家認為只有 650 萬筆資料洩漏,但實際上在 2016 年的現在被確認有 1.17 億筆。
官方也確認 2016 的這份洩漏是正確的,兩份公告在:
很多人都收到 password reset 信件了...
在「Hostnames and usernames to reserve」這邊提到公開服務時的保留名稱問題。
首先是提到 hostname 的部分,被各協定使用到的都散落在各標準裡,另外就是利用前幾天提到的「Mozilla 維護的 Public Suffix List」加減擋 cookie...
比較感興趣的是 email 的部分的標準,這邊主要在討論 SSL certificate 的註冊。在「Baseline_Requirements_V1_3_1」的 3.2.2.4. Authorization by Domain Name Registrant 的第四項提到:
Communicating with the Domain’s administrator using an email address created by pre‐pending ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, or ‘postmaster’ in the local part, followed by the at‐sign (“@”), followed by the Domain Name, which may be formed by pruning zero or more components from the requested FQDN;
也就是指出只能用上面提到的這幾個 mail address 來認證。不過為了安全起見,RFC 2412 定義的也應該擋下來。這兩組標準列出來的 username 都算是合理,沒什麼問題。
最後則是討論 path part,這點倒是有不少地雷可以看看,尤其是最新的 ACME 產生的問題 XDDD
在「“Invalid Username or Password”: a useless security measure」這篇文章裡談到了使用者登入錯誤時的提示訊息。
通常為了安全考量,「沒有這個帳號」與「密碼錯誤」,我們會給出一樣的錯誤訊息,避免攻擊者可以猜測。像是 Amazon 的畫面:
這樣設計的前提是讓攻擊者不知道這個帳號是不是存在 (如果不存在的話就換其他帳號繼續攻擊)。但這個假設通常是錯的,因為大多數的系統一個 e-mail 綁定一個帳號,所以註冊時就可以分辨:
因此應該提供正確的訊息,而非將資訊隱蔽起來。