強迫要求使用者改密碼反而會不安全?

在「Want Safer Passwords? Don't Change Them So Often」這邊在討論改目前 password policy 會有要求一定時間要改密碼造成的問題。原報導出自 美國聯邦貿易委員會 blog 上的「Time to rethink mandatory password changes」。

當你強制要求改密碼時,由於因為是被逼的,他們不會放太多心力:

Lorrie Cranor recently outlined, the weight of recent research agrees that when people are forced to change their passwords on the regular, they don’t put a whole lot of mental muscle behind it.

而在沒有準備的情況下產生出來的密碼將會是比較容易預測的:

Instead, Cranor notes, according to one UNC study, people “tended to create passwords that followed predictable patterns, called ‘transformations,’ such as incrementing a number, changing a letter to similar-looking symbol (for example changing an S to a $), adding or deleting a special character (for example, going from three exclamation points at the end of a password to two), or switching the order of digits or special characters (for example moving the numbers to the beginning instead of the end).”

另外你應該鼓勵使用者用 password manager 管理密碼,雖然不是完美的,但至少是目前比較合理的方案:

If for whatever reason you still can’t let go of making people change passwords as often as they turn the pages of their wall calendars, Cranor suggests that you at least encourage them to use a password manager, like LastPass or DashLane. They’re not perfect, but they can be a “very reasonable strategy” for coping, mostly because they don’t require people to balance unpredictable passwords with ones they can actually remember.

關於 RDBMS 的 Schema Migration...

在「NoSQL 大腸花」這份投影片裡面的 Page 12 有提到關於 RDBMS 的 Schema Migration:

以目前 open source 的兩個專案,MySQLPostgreSQL 來看,裡面提到的 lock 應該都不是問題...

首先是 MySQL 的部份,真的量大的網站都應該是往 InnoDB 投靠,而 pt-online-schema-change 在這個領域則是處理的很好。

Facebook 的 Mark Callaghan 曾經在 2010 年寫過一篇關於 InnoDB 的 online schema change 的原理:「Online Schema Change for MySQL」,主要是利用 Trigger 的機制,用七個步驟架構出沒有 downtime 的 online scheme change。

就算不考慮 pt-online-schema-change 這種工具,在 MySQL 5.6 開始,就有愈來愈多 ALTER TABLE 的行為是不會影響到 read/write 了:「Avoiding MySQL ALTER table downtime」。

而 PostgreSQL 的情況也差不多,常見的 ALTER TABLE (新增與刪除 column 與 index) 也都不會影響 read/write。

這些在 Stack Overflow 上有不少討論:「ALTER TABLE without locking the table?」。

MySQL 在 RDBMS 領域裡比起來的確是不怎樣,不過沒有這麼糟糕啊...

利用 pt-online-schema-change 同步 master 與 slave 的資料

在「Syncing MySQL slave table with pt-online-schema-change」這篇看到 master 與 slave 的資料不同步時,強制性同步的方法:

pt-online-schema-change --alter 'ENGINE=INNODB' D=dbname,t=tblname

由於 pt-online-schema-change 的作法是建一個新的表格,然後把舊表格的資料寫過去,而這些行為會被 replicate 到新機器上,於是就同步了...

這招有趣 XDDD

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝),像是這樣的架構:

其中 node{1,2} 為 cluster,node3 則是傳統的 async replication,來源的 master 為 node1。

當 node1 掛掉時,我們沒辦法自動將 node3 的 master 從 node1 改指到 node2,因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值,這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的,就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO,而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後,就有機會寫成程式自動化... 這算是一個不錯的開頭 :p