アカウント名:
パスワード:
最大6桁程度でも、3～6桁の任意桁数を許容してさらに「右詰」「左詰」「中央揃え」入力が選択できると結構自由度が増す気がします。
断固抗議します。
顧客 ID には数字しか入らないことが仕様上明らかなのに、KOKYAKU_ID varchar2(10) のようなテーブル定義をするコボラーが今でさえうじゃうじゃいるのに。彼らをいかに早く絶滅させられるかが 21 世紀の IT 技術者の使命なのです。
(以下 65KB 分の愚痴が省略されました。続きを読むには……)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
4桁・・・ (スコア:1)
もう少し桁数を増やしたほうが・・・
４桁で類推できる番号を使えなくすると、逆に類推できてしまうんじゃ・・・
え？もう４桁じゃない？
Minder
Re:4桁・・・ (スコア:2, すばらしい洞察)
６桁の暗証番号に変更させられました。
はたしてそれが強化になったといえるのかは疑問ですし、使用頻度は
キャッシュカードほど高くないので日数が経つと忘れてしまいます。
４桁が６桁になったって、セキュリティは「下の下」が「下」くらいに
なった程度でしかなく、効果は薄いです。
一人で短期間で攻略できるのが４桁、数人で数日かかるのが６桁という
差ではないでしょうか。
ツールなんかを使って機械的にやれば、４桁も６桁も変わらないかも。
それよりも数字のみではなく、アルファベットも使わせて欲しいです。
人間は数字だけよりもアルファベットを入れたほうが覚えやすいですし、
他人からは推測しにくいものも簡単に作れます。
Re:4桁・・・ (スコア:1)
最大6桁程度でも、3～6桁の任意桁数を許容してさらに「右詰」「左詰」「中央揃え」入力が選択できると結構自由度が増す気がします。
効果ないかなぁ。
Re:4桁・・・ (スコア:0)
Re:4桁・・・ (スコア:0)
断固抗議します。
顧客 ID には数字しか入らないことが仕様上明らかなのに、KOKYAKU_ID varchar2(10) のようなテーブル定義をするコボラーが今でさえうじゃうじゃいるのに。彼らをいかに早く絶滅させられるかが 21 世紀の IT 技術者の使命なのです。
(以下 65KB 分の愚痴が省略されました。続きを読むには……)
Re:4桁・・・ (スコア:0)
number(10)にしたってどうせ2進化10進数で格納されるんだから、ディスク領域をちょっと節約できるだけでしょ。比較の速度だって大して違わないんだし、将来の変更のこと考えたらvarchar2で何も問題ないと思うけど。
Re:4桁・・・ (スコア:0)
Re:4桁・・・ (スコア:0)
6桁というと凡そ百万通りの候補があるんですが、それだけの候補を
次から次へと試していく間、システム側はハラハラしながらそれを
見てるしか手がないんですかい？
パスワード破りの方法として、虱潰しにやるか、別情報から類推するかで、
4桁から6桁への移行は、4桁は類推されやすい候補がありふれてるんで、
6桁なら大丈夫だろうという趣旨じゃないかな。そして、虱潰しの攻撃には
> ４桁も６桁も変わらないかも。
かもしれないが、チャレンジ数回失敗で口座を使用停止とかにすることで
対処できるんじゃない？
Re:4桁・・・ (スコア:1, すばらしい洞察)
Re:4桁・・・ (スコア:0)
> 対処できるんじゃない？
過去の例ですと、電話で操作できるサービスでは暗証番号を
何度間違えても凍結されない脆弱性があったり、暗証番号は
固定で、口座番号を少しずつ変えてチャレンジするという
手口もあったようです。
それに、類推されやすい番号は除外できるわけですから、
逆に候補が絞れるわけです。
類推されやすい暗証番号を使っていれば、その本人に責任が
あるでしょうけど、もともと類推されにくい暗証番号を使って
いる人は、候補が削減されることでセキュリティのレベルが
低下することになったのですよね。
Re:4桁・・・ (スコア:0)
適当に考えてみた。
a:4
b:13
c:6
d:9
e:6
f:7
g:8
h:5
i:1
j:1
k:12
l:6
m:3
n:2
o:0
p:10
q:9
r:12
s:5
t:7
u:01
v:4
w:3
x:8
y:7
z:2
#探せば、もっとまともなのがありそう。
#上手く検索できんかった、というか、別にどうでもいいんで、こんな感じで暗証番号に使ってたりします。