PTT職涯區 / Soft_Job (軟體人)

Fw: [軟體] 電子商務客戶端app輸入資料正確性驗證?

看板Soft_Job (軟體人)作者 (無業遊民)時間9年前 (2016/09/02 22:38), 9年前編輯推噓6(6推 0噓 35→)
留言41則, 3人參與, 最新討論串1/2 (看更多)
※大家好，第一次來貴版發文，若有板規需注意的請不吝提醒 題目還蠻複雜的，想發軟體版但是不確定應該發在哪裡，且又是手機app就發在這了 我所上班的公司有電子商務的業務，且也有發行客戶端app可供使用 在這塊業務部份有個問題是： 若公司要付錢給客戶，要如何確保客戶端app輸入的資料確實是客戶的帳戶？ 目前在未使用App輔助的狀況下是靠人力去聯絡客戶驗證帳戶無誤 現已有的技術就是OTP(one time password)動態密碼， 有一家公司叫iDGate的則是有方法將app綁定客戶的手機「推播互動式安全認證」。 我不確定能不能解決這樣的問題 「我請別人用app幫我key資料,公司要怎麼防範他key的不是我的資料」 目前想到的都還是要靠人力驗證，程式上有能降低人力或是不需人力使用的辦法？ -- 20330 6/17 - □ (本文已被吃掉) 幹!這梗有毒...救命~~ 20331 6/17 - □ (本文已被吃掉) 〒 〒 ◤ 20332 1 6/17 - □ (本文已被吃掉) ▼▼▼▼ 20333 XX 6/17 - 囧 (哈哈拎北有毒) \▲▲▲▲\ = ●20334 1 6/17 - □ (本文已被吃掉) 20335 6/17 - □ (本文已被吃掉) 口卡口卡嚐百草 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.166.242.50 ※ 文章網址: https://www.ptt.cc/bbs/Android/M.1472820624.A.B25.html
→
09/02 23:23, , 1F
看不太懂，你是說要防止有人假冒客戶來收錢嗎？
09/02 23:23, 1F
→
09/02 23:24, , 2F
你把改帳戶當成改密碼處理就可以啦，兩步驗證套路一堆堆
09/02 23:24, 2F
怕有不肖人士借客戶的手機更改帳號為自己或第三人的帳號，跟您的意思應該差不多 稍早的時候是有想到若有異動的時候會發一則有免付費客服電話的訊息給客戶撥打 但就是增加公司人力和電話成本，且這項流程就算不靠app，在異動帳號時會發生
→
09/03 00:03, , 3F
第二黃色是校對問題。怎麼樣都要有正確首版本。
09/03 00:03, 3F
這點很困擾，程式防不了人心舞弊，只能仰賴人力驗證，原希望靠app能減少人力...
→
09/03 00:43, , 4F
如果你是要驗證App端使用者輸入的收款用銀行帳戶
09/03 00:43, 4F
→
09/03 00:44, , 5F
可以跟你們自己配合的銀行談談看有什麼方式可以支援
09/03 00:44, 5F
金控端原則上是樂見客戶在自家銀行開戶，但是客戶願不願意為了領錢另外開戶無法控制
推
09/03 00:45, , 6F
另一種是透過警告提示的部份，需與銀行帳戶戶名相同 等 blah
09/03 00:45, 6F
→
09/03 00:45, , 7F
blah 的文字 這種範本很多
09/03 00:45, 7F
→
09/03 00:46, , 8F
若你們沒把握 盡可能撥款給某會員 該會員需實名
09/03 00:46, 8F
→
09/03 00:47, , 9F
同時盡量讓系統上的客戶收款帳號不該被重複
09/03 00:47, 9F
推
09/03 00:53, , 10F
系統盡量加入實名認證 以及加入一組只有使用者知道的請款密
09/03 00:53, 10F
→
09/03 00:53, , 11F
碼
09/03 00:53, 11F
我原本的想法是不管有無異動，在客戶透過app回饋資料時，公司就會發送一則驗證序號 請客戶時限內輸入後確認，代表客戶確實有做這筆交易，但即使如此還是無法防範客戶 將綁定的手機出借請業務代為操作(畢竟客戶層廣且多，不諳app功能的應該所在多有)
→
09/03 00:55, , 12F
這樣可以防止別人手賤開App竄改收款帳戶時
09/03 00:55, 12F
→
09/03 00:56, , 13F
還有一道門擋著
09/03 00:56, 13F
推
09/03 00:58, , 14F
也可以再加入審核時間的設計，也就是原本的收款帳戶被更新，
09/03 00:58, 14F
→
09/03 00:58, , 15F
需要一個小時或一天的時間才能做請款
09/03 00:58, 15F
這點我覺得不錯，就是一個系統訊息告知客戶須一定時間給公司做驗證 驗證無誤後即可於何時撥款，目前線上借款的業務有類似的風控設計
→
09/03 00:59, , 16F
要多複雜看你公司營業的項目是什麼然後給他適當的防護措施
09/03 00:59, 16F
→
09/03 00:59, , 17F
太雜也挺惱人的
09/03 00:59, 17F
各種保險金給付，對象原則上是受益人/要保人，但很怕業務有冒名的風險
推
09/03 01:02, , 18F
另外再補充一點 當客戶要請款時 可以做成排程 也就是說使用
09/03 01:02, 18F
→
09/03 01:02, , 19F
者進行請款時
09/03 01:02, 19F
→
09/03 01:03, , 20F
系統會告知客戶將在什麼時候撥款至他的戶頭
09/03 01:03, 20F
→
09/03 01:04, , 21F
若有XX問題，在YY時間內可以進行取消。
09/03 01:04, 21F
推
09/03 01:10, , 22F
這種設計方式可以防止你們系統遭到特定集團鎖定入侵時(例如
09/03 01:10, 22F
→
09/03 01:10, , 23F
有人持有大量的帳號密碼，透過撞庫的方式登入)
09/03 01:10, 23F
→
09/03 01:11, , 24F
在系統上大量的進行異常的請款動作
09/03 01:11, 24F
→
09/03 01:11, , 25F
可以不會一次全部都把錢洗走
09/03 01:11, 25F
→
09/03 01:16, , 26F
然後再記得將取消請款的部份做統計
09/03 01:16, 26F
→
09/03 01:17, , 27F
系統有人看 或當某時間區間請款取消的次數到達一個設定值系
09/03 01:17, 27F
→
09/03 01:17, , 28F
統立即通報管理層的所有人員立即處理
09/03 01:17, 28F
→
09/03 01:18, , 29F
半夜的時候則暫時停止所有情款之類的動作
09/03 01:18, 29F
→
09/03 01:18, , 30F
請*
09/03 01:18, 30F
※ 編輯: Chih3300625 (118.166.242.50), 09/03/2016 01:40:42
→
09/03 01:21, , 31F
大概就差不多這樣 希望有幫上你的忙@@
09/03 01:21, 31F
推
09/03 02:28, , 32F
大致上看懂了，不過我個人認為此題無解
09/03 02:28, 32F
→
09/03 02:30, , 33F
如果無法阻止業務接觸用戶手機的話，任何程式上的驗證都無解
09/03 02:30, 33F
→
09/03 02:33, , 34F
修正一下，是任何自動驗證都無解，需要人工介入
09/03 02:33, 34F
→
09/03 02:34, , 35F
所以我覺得可能要靠流程控管的方式來降低風險，舉例來說：
09/03 02:34, 35F
→
09/03 02:35, , 36F
1. alog 提到的排程 + 通知
09/03 02:35, 36F
→
09/03 02:36, , 37F
2. 限制 app 端只能變更帳號為原帳號的 "同戶名約定帳號"
09/03 02:36, 37F
→
09/03 02:39, , 38F
3. 定合約要業務負責承擔惡意操作的風險
09/03 02:39, 38F
→
09/03 02:40, , 39F
感覺沒有幫助到原po 哭哭
09/03 02:40, 39F
→
09/03 09:00, , 40F
第一黃色可以使用公司名義和電信業者洽談。政策優先技術
09/03 09:00, 40F
→
09/03 09:01, , 41F
黑暗面真的就是我拿到倒楣鬼個資，只有帳戶填洗錢帳戶。
09/03 09:01, 41F
‣ 更多 Chih3300625 的文章
文章代碼(AID): #1NoOxXc3 (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 Chih3300625 的文章
文章代碼(AID): #1NoOxXc3 (Soft_Job)