[閒聊] DB 誤刪了服務的使用者密碼怎麼辦

看板Soft_Job作者 (自立而後立人)時間10年前 (2013/12/20 16:10), 編輯推噓34(34推 0噓 87→)
留言121則, 45人參與, 最新討論串1/1
強者我朋友今天說了一個歷史悠久的鄉野奇談，姑妄言之姑聽之。 很久很久以前，有人不小心下錯 sql ，大概是類似這樣 update users set password = pass('test') 但忘了上 where ，所以就所有人密碼被改。 到這裡我們以為解決方案一定是撈備份，但想當然爾早期根本很多人沒這習慣， 就....悲劇。 下一招一定是叫使用者回來確認密碼～～但這樣就會被發現有人幹蠢事了。 最後他們想了一個招解決這個問題： 使用者打第一次密碼時回應使用者輸入錯誤，但偷偷把這密碼更新成正式密碼， 使用者第二次打密碼時就用剛剛的密碼去比對.... 聽說好像後來只有很少的使用者有抓包這件事情 XDDDDDDDD by 不可思議事件之好孩子不要學之民明書房 FB 好友表示......XDDD https://www.facebook.com/tonylovejava/posts/10202918985041326 -- 資訊界很有些聽起來很恐怖，但卻又是聽得出來其背後血淚/真實性的(鬼)故事啊。 XD 人家是聊齋誌異，這是聊齋"資"異。 -- Life's a struggle but beautiful. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.166.93.88 ※ 編輯: TonyQ 來自: 118.166.93.88 (12/20 16:12)
推
12/20 16:23, , 1F
笑翻XDDD 快學起來(不對
12/20 16:23, 1F
→
12/20 16:24, , 2F
這叫作置之死地而後生~
12/20 16:24, 2F
推
12/20 16:43, , 3F
在我待過的公司這樣就被LAY了八
12/20 16:43, 3F
→
12/20 16:44, , 4F
我是覺得下之前也應該放在測試資料庫跑一次看看
12/20 16:44, 4F
→
12/20 16:45, , 5F
會這樣大概都是習慣不好
12/20 16:45, 5F
→
12/20 16:46, , 6F
帥!! 這是變相的轉個彎系列吧
12/20 16:46, 6F
→
12/20 16:46, , 7F
而且這位前輩的環境就算沒有內稽內控規範也不能鐵齒
12/20 16:46, 7F
→
12/20 16:47, , 8F
還是認真做備份吧，我現在都會乖乖做備份了=_=
12/20 16:47, 8F
→
12/20 16:47, , 9F
其實兩個部份都有問題，沒有備份的問題比較大，另一方面是
12/20 16:47, 9F
→
12/20 16:48, , 10F
寫 update 之前還是盡量先寫完 where 再寫修改內容
12/20 16:48, 10F
→
12/20 16:48, , 11F
嗯。先寫成 select 看一下範圍是很重要的習慣啊
12/20 16:48, 11F
推
12/20 16:58, , 12F
其實還滿聰明的..XD
12/20 16:58, 12F
→
12/20 17:02, , 13F
先select +1...
12/20 17:02, 13F
→
12/20 17:04, , 14F
我覺得要加薪 想到這個方法的人 這個人有頭腦
12/20 17:04, 14F
→
12/20 17:04, , 15F
減薪造成這個失誤的人 不夠謹慎
12/20 17:04, 15F
→
12/20 17:04, , 16F
如果都是同一人 ....哈哈哈 XD
12/20 17:04, 16F
推
12/20 17:12, , 17F
想到的人很威...
12/20 17:12, 17F
→
12/20 17:14, , 18F
同意q大。現在有動到刪除、更新..都會用SELECT確認一下
12/20 17:14, 18F
→
12/20 17:24, , 19F
如果是工具的話別用autocommit
12/20 17:24, 19F
推
12/20 17:37, , 20F
我幹過兩次類似的事情，不過不是改密碼 是改線上系統
12/20 17:37, 20F
推
12/20 17:55, , 21F
個人一定會先Select後將結果備份，然後再寫Update
12/20 17:55, 21F
→
12/20 17:56, , 22F
如果是正式環境，還會先做一次完資料庫備份
12/20 17:56, 22F
→
12/20 17:57, , 23F
萬一手滑了,你不就出包了?
12/20 17:57, 23F
→
12/20 17:58, , 24F
第一次不小心打錯...第二次打正確的...永遠都進不去了
12/20 17:58, 24F
推
12/20 18:00, , 25F
樓上那個好解 連續2次一樣才當正式密碼
12/20 18:00, 25F
推
12/20 18:01, , 26F
UPDATE的話都會用編輯工具 囧 驚驚
12/20 18:01, 26F
推
12/20 18:11, , 27F
update delete 單筆的話 必定搭limit 1
12/20 18:11, 27F
推
12/20 18:19, , 28F
難怪有時候輸入正確他也跟我說不正確,原來..XDD
12/20 18:19, 28F
推
12/20 18:22, , 29F
這哪招啊XDDDD
12/20 18:22, 29F
推
12/20 18:30, , 30F
拿 production 做測試本身就是個錯誤 Orz
12/20 18:30, 30F
推
12/20 18:36, , 31F
原來還有這招，誰想到的阿XDDDD
12/20 18:36, 31F
→
12/20 18:39, , 32F
資料不進行備份的公司還漫酷的..
12/20 18:39, 32F
推
12/20 18:41, , 33F
普通用戶在終端機設陷,找機房管理員偷root帳號的變形老招
12/20 18:41, 33F
→
12/20 18:41, , 34F
線上資料 測試資料 線上程式 測試程式也沒切開
12/20 18:41, 34F
→
12/20 18:42, , 35F
我怎覺得管理面的問題比失守犯錯的問題大多了
12/20 18:42, 35F
→
12/20 18:44, , 36F
這樣幹的話 要登入任何一個人的帳號只要在他之前
12/20 18:44, 36F
→
12/20 18:44, , 37F
輸入兩次同樣的密碼就...
12/20 18:44, 37F
→
12/20 18:50, , 38F
魚怎麼會知這是有鉤的魚餌?搶食到食物的魚都會帶食快離去
12/20 18:50, 38F
推
12/20 18:53, , 39F
同樓上，我也想到這問題
12/20 18:53, 39F
還有 42 則推文
→
12/21 09:57, , 82F
前陣子YAHOO很多帳號被強迫換密碼 該不會和這有關?
12/21 09:57, 82F
→
12/21 09:59, , 83F
這招也不是很好 像我密碼有好幾組 錯了我會換另一組
12/21 09:59, 83F
→
12/21 10:00, , 84F
常用密碼測試
12/21 10:00, 84F
→
12/21 10:02, , 85F
還有就是帳號打到別人的,密碼打到自己的這種情形
12/21 10:02, 85F
→
12/21 11:07, , 86F
其實為了一個SQL的錯誤，要改使用該資料的應用程式
12/21 11:07, 86F
→
12/21 11:07, , 87F
只能說，這不是一種好方法
12/21 11:07, 87F
→
12/21 11:08, , 88F
另外，我個人在寫非SELECT的SQL指令時，會包在註解裡
12/21 11:08, 88F
→
12/21 11:08, , 89F
以免不小心按了全部執行
12/21 11:08, 89F
→
12/21 11:09, , 90F
個人一向認為，所有的資料庫變更應該要由應用程式來做
12/21 11:09, 90F
→
12/21 11:11, , 91F
應該要避免直接在資料庫中執行SQL指令
12/21 11:11, 91F
→
12/21 11:12, , 92F
尤其是Update、Delete、Insert。我認為這是走後門的做法
12/21 11:12, 92F
→
12/21 11:13, , 93F
但我接觸的客戶跟老闆，都認為直接下比較方便
12/21 11:13, 93F
→
12/21 11:15, , 94F
上面寫的解決方法有資安問題，只是個掩飾錯誤的做法
12/21 11:15, 94F
→
12/21 11:17, , 95F
過段時間一定要改回來，再加寫忘記密碼或密碼重置功能
12/21 11:17, 95F
推
12/21 11:18, , 96F
這沒被FIRE算奇蹟
12/21 11:18, 96F
→
12/21 11:18, , 97F
其實看過很多系統，不是沒有備到份，就是備份無法回復
12/21 11:18, 97F
→
12/21 11:19, , 98F
所以不是有備份到就行了，還必須要能復原
12/21 11:19, 98F
→
12/21 11:20, , 99F
讓我想起很久以前，被客戶要求星期日來做異地備援備份與回
12/21 11:20, 99F
→
12/21 11:21, , 100F
複演練。在演練前還要把動作及時間寫成文件，然後照做
12/21 11:21, 100F
→
12/21 11:22, , 101F
若有失誤或時間內沒有做完，就會被要求檢討改善
12/21 11:22, 101F
→
12/21 11:23, , 102F
因為會被FIRE，所以才會想到要用這樣的方法來解決
12/21 11:23, 102F
→
12/21 11:24, , 103F
工作 vs 資安，當然是工作比較重要
12/21 11:24, 103F
推
12/21 11:53, , 104F
抄起來了
12/21 11:53, 104F
推
12/21 14:36, , 105F
發封信說為增加密碼安全請使用者定期改密碼，之後當下
12/21 14:36, 105F
→
12/21 14:36, , 106F
強迫他去改密碼 這樣如何?
12/21 14:36, 106F
→
12/21 23:44, , 107F
要改密碼，在正常的程序是必須成功驗證過密碼的
12/21 23:44, 107F
→
12/21 23:45, , 108F
沒有密碼，還想要改使用者密碼，就必須要另外檢核使用者的
12/21 23:45, 108F
→
12/21 23:46, , 109F
身分，也就是忘記密碼功能。如果只有一、二個人的密碼被改
12/21 23:46, 109F
→
12/21 23:47, , 110F
還可以硬說是使用者忘記密碼了，但如果是整個資料表就很難
12/21 23:47, 110F
→
12/21 23:48, , 111F
說得過去，必須要掩飾錯誤
12/21 23:48, 111F
推
12/22 00:54, , 112F
看推文長知識
12/22 00:54, 112F
推
12/23 14:02, , 113F
astt8,我觀念跟你一樣,DB資料的變更應由AP而非DBA.從業以來
12/23 14:02, 113F
→
12/23 14:02, , 114F
遇到一個很特別的客戶,AP有提供系統功能修改資料,但客戶要求
12/23 14:02, 114F
→
12/23 14:03, , 115F
把系統功能從授權移除,資料維護廠商一律提供SQL腳本...
12/23 14:03, 115F
→
12/23 14:05, , 116F
執行資料維護的系統功能都有log,並需放行後資料才會生效.
12/23 14:05, 116F
→
12/23 14:06, , 117F
結果居然都要求提供SQL,真是特別!
12/23 14:06, 117F
推
12/23 14:09, , 118F
另外問一下astt88,您被客戶要求週日做備援演練,有收費嗎? XD
12/23 14:09, 118F
→
12/23 22:12, , 119F
因為是做異地備援案，所以應該沒有額外收費
12/23 22:12, 119F
→
12/23 22:13, , 120F
異地備援案的金額我不知道，那時我不是正式的員工
12/23 22:13, 120F
→
12/23 22:14, , 121F
所以假日去客戶那邊做備援演練，只能換補休
12/23 22:14, 121F
‣ 更多 TonyQ 的文章
文章代碼(AID): #1Ii_jniy (Soft_Job)