2019年07月の日記です

目次

12日 いきてますよ
14日 パスワードの管理方法(令和元年版)


いきてますよ  2019-07-12 16:48:46  その他

▲目次へ ⇒この記事のURL

先月19日からだから、3週間ほど日記を書いてなかった。


その前に少し書いていたが、取引先を変えて仕事内容が大きく変わった。

それで忙しくて日記を書いてなかった。


より正確に言えば、「忙しくしていたので特に日記に書きたい面白いネタがなかった」だな。

忙しくても、ネタさえあれば日記を書く暇くらいは捻出する。




これだけだとあまりにも寂しいので、新しくやっている仕事について少し書いておこう。


具体的に何をやっているかは書かない。

別に企業秘密とか守秘義務とかではなくて、「宣伝になるから書いていいよ」と言われているのだけど、なんとなくまだ書く段階にないように思うから。


で、大きく分けて3つの仕事を同時にこなしている。


・WEB ブラウザで動作する、HTML + Javascript クライアントプログラム。素の Javascript だ。

 WEB socket で得たリアルタイムデータを SVG でグラフィカルに表示し、同時に WEB Audio で音を出す。

 作っていてなかなか楽しい。



・WEB ブラウザで連携動作する、Javascript + Vue.js クライアントプログラム。

 まぁ、Vue を使おうが使うまいが、究極的には HTML + Javascript ではある。

 しかし、複数ファイルに分けて書いたものをコンパイル・統合して配布ファイルを作る、というような、環境的には全く素の Javascript とは異なるものだ。


 上に書いたプログラムとは完全別物だが、同じ大きなシステムの中の一部。

 実は前任者が途中まで作り上げたプログラムを引き継いだので、まだ完全把握に至っていない。

 しかし、Vue はなかなか興味深いプログラムスタイルだ。自分が一から作っていたら使わなかったと思うが、良い経験をさせてもらっている。


・上に書いた Vue プログラムは、もともとは PHP で書かれていたサーバープログラムを「移植」したもの。

 PHP で複数ページにわたっていたプログラムを、Vue.js によって一つにまとめ、ページ遷移をすべてブラウザ側レンダリングで解決するようにしている。


 となると、当然 DB とやり取りする部分をサーバー側に作り込む必要があるが、このプログラムは node.js で作成されている。

 この部分も、Vue のプログラムを作っていた人が途中まで作っていたのを引き継いだ形。


 以前仕事で node.js を使ったことはあって、その時の感想は「仕事で node.js を使うのはリスクが大きい」だった。

 その頃は node.js はまだ新しいもので、環境が十分に整っていなかった。

 本体やライブラリのバージョンアップのたびに、致命的な非互換が生じていた。


 しかし、近頃の node.js は、当時と比べるとずっと安定しているようだ。



というわけで、3つの仕事ではあるが、全部 Javascript。

しかし、使ったことがある人ならわかると思うが、素の Javascript と、Vue などを使った Javascript と、node.js を使った Javascript は、環境的にかなり違う。


中途半端に Javascript という同じ部分を共有しているため、妙に混乱する。

(node.js の Javascript いじったのに、ブラウザリロードするだけで「動かない」と悩んでしまったり。

 node.js はサーバーサイドなので、デーモンの再起動が必要)




まぁ、そんな感じのことやってます。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

その他

別年同日の日記

02年 納得?

15年 実装の苦労

16年 Chromebook購入

16年 Chromebook で子供ができること

17年 ジョージ・イーストマン 誕生日(1854)

18年 メモリアドレス


申し訳ありませんが、現在意見投稿をできない状態にしています

パスワードの管理方法(令和元年版)  2019-07-14 11:47:37  コンピュータ 歯車

▲目次へ ⇒この記事のURL

5年も前に書いた記事に、ご意見をいただいた。

記事の間違いを指摘してくれたものだ。


以前からたびたび書いているが、僕は自分の知識が正しいとは思っていない

5年も前の記事なら状況も変わっているだろうからなおさらで、こうした指摘はありがたい。


しかし、今回に関してはどうもご指摘がおかしいように思えた。

最新の情報では変わっていたりするかも…と念のため調べたが、今でも僕の書いた記事は有効なようだ。


どうも、ご指摘が勘違いからくる誤りのようだが、一人ご指摘をくれたということは、それ以上に多くの人が同じような勘違いをしているように思う。

そのため、過去の記事の内容を解説し、指摘がどう誤っているのかを記しておく。




まず、過去記事の概要。


パスワードは紙に書いてはダメで、すべて記憶するのが正しい、と思っている人が多いことに対して、その間違いを指摘した記事だ。

(これも5年前の話なので、今でもこう思っている人は減っている、と思いたい)


パスワード管理する上で、重要なのは


・サイトごとにすべて変更する。

・ほぼランダムに見える文字列を使う。

・時間的にも時々変更する。


の3点で、これらの決まりを守ろうとすると、パスワードを記憶する、というのは難しくなる。



そのため、20世紀には、「パスワードは紙に書かず、記憶するのが正しい」とされた時代はあるが、現代においては紙に書くのは悪い手段ではない、と解説したものだった。



これに対して、いただいた意見は「時間的な変更」をやってはならない、とするものだった。

時間的に変更することを促すと、パスワード管理が雑になり、セキュリティが弱くなる、という指摘だった。




この指摘は、2017 年に NIST (米国国立標準技術研究所)が勧告したパスワード管理方法を踏まえたものだろう。

僕の記事は 2014 年に書かれたもので、情報が古くなり意味を失った、と捉えることもできる。


NIST は、米国政府関連で求められる認証方法について、時代に合わせて適切なセキュリティ強度を保つための勧告をまとめている。



2017 年の報告では、パスワードを設定する際のユーザーインターフェイスなどについてもまとめている

ここには「パスワードの変更を強要すべきではない」という趣旨が書かれている。



これを受けて、国内でも総務省が「安全なパスワード管理」という呼びかけページを作成した。



ここに、パスワードの「定期的な変更は不要」と書かれている。


これがちょっと問題ありで、見出しに大きな文字で「定期的な変更は不要」と書かれてしまった。

内容を読むと、変更が不要なのではなく、「パスワードの定期的な変更を要求すべきではない」と書かれている。


この内容自体、 NIST の勧告に基づくものだ、と書かれていて、趣旨も同じだ。

あくまでも「変更の要求」に問題があるとするものだ。


しかし、見出しに「定期的な変更は不要」と書いてしまったために、多くの人が勘違いしてしまった。

新聞報道などでも「パスワードは変更しない方が良い」として広まってしまった。




NIST の勧告はセキュリティのためだけではなく、ユーザーの利便性を考えて「システムによる行き過ぎた規制」を緩和しようとしているものだ。


パスワード変更を強要すべきではない、という文脈には、「異なる文字種の混合を要求したりしてはならない」というものも入っている。


異なる文字種…数字、大文字、小文字、などだ。

この3つを、それぞれ少なくとも1つ以上は使うように求めるシステムは結構多い。

それらを混ぜることで、セキュリティが高まると期待しているのだ。


しかし、NIST はこれを禁じている。

ここにあるのは「ユーザーに不便を強いるな」という意図であり、セキュリティ強度とは無関係の話だ。


(一応、文字を混ぜても期待するほどセキュリティ強度は上がらない、という解説が巻末についているけど)



以上のように、NIST 勧告の「時間的な変更をやってはならない」は、システムに組み込むべきではないという指針だ。

それに対し、僕が過去記事に書いたのは、各ユーザーが自発的にとるべき、パスワード管理の心得を書いたものだ。


これらは全く性質の異なるものだ。



しかし、今回いただいたご指摘は、これを混同したものだった。

異なるものを混同し、「パスワードを変更してはならない」と考えていると、セキュリティ上のリスクを生じてしまう。




なぜ時間的な変化が必要かを示そう。


単純な話、パスワードはいつか破られる。

もちろん、攻撃側にその気があれば、の話だけど。



攻撃者がパスワードを知る方法なんて、いくらでもある。


たとえば、パスワードハッシュファイルの入手。

詳細は5年前の記事を参照してほしいが、攻撃者がパスワードハッシュを入手した場合、比較的「覚えやすい」パスワードなら、解明されてしまうだろう。


覚えにくい…ランダム文字列は、解明を遅らせることができる。

だから、「ほぼランダムに見える文字列を使う」という指針が入ってくる。



その一方で、キーロガーと呼ばれるような手段を使い、あなたが入力するパスワードを「直接」記録する方法もある。

この方法で奪われた場合は、キー入力がそのまま漏れてしまうため、文字列がランダムに見えるかどうかは関係ない。


あとは、パスワードが「漏れた」前提の話となる。


被害を最小限に食い止めるためには、そのパスワードが使える場所を限定しておくことだ。


「サイトごとにすべて変更する」というのは、そのための指針となる。




では、最悪の状況、実際に被害が出たとしよう。

問題は、それがどのような被害だったか、ということだ。


「勝手に買い物」された場合は、身に覚えのない請求が届くので気づくだろう。

しかし、メールなどを覗き見られて生活を丸裸にされている場合には、パスワードが漏れたと気づくだろうか?


時間的に変化させる、というのは、こうした気づかない被害に対する防御策だ。


大規模なパスワード流出があった、というような状況では、世間的にもパスワードの変更が呼び掛けられる。

パスワードが「漏れたかもしれない」と思えば、変更しておくのが良いだろう。


が、ストーカー被害の場合は身近な人によるショルダーハッキング…あなたが会社の PC などを操作しているときに、後ろからパスワードを覗き見ただけ、などの可能性がある。


キーロガーすら使わない。パスワードは、漏れるときは本当に簡単に漏れる。

そうした状況では、自分のパスワードが漏洩した、と気づくのは難しい。



NIST では、「第三者のログインに気づくようなシステム」を構築することも推奨している。

そうしたシステムなら、パスワードが漏洩し、情報を覗き見られていることにも気づくかもしれない。


しかし、残念ながらそうではない WEB サービスが多い。


ここでの自衛策は、時々パスワードを変えることだ。

普段から時々パスワードを変える、という習慣を持っていれば、パスワードが第三者に知られたとしても、被害をある程度の範囲で食い止めることができる。


「時間的にも時々変更する」というのは、そのための指針だ。




ただ、ここでいう「変更すべき」なのは、ユーザー各自の裁量に任されていることに気を付けてほしい。


先に書いた通り、NIST は「変更を強制すべきではない」とするだけで、この件についてあまり触れていない。

しかし、「強制的にパスワード変更を促す」システムは弊害しかない、というのはセキュリティ専門家の多くの意見が一致するところだ。



定期的に変更すべき、と言われて自主的に変更するユーザーは、セキュリティ意識が高い。

当然、変更の際にも妥当なパスワードを設定するだろう。


しかし、特にセキュリティ意識がなく、パスワードを「面倒だけど設定しないといけないもの」程度にしか思っていない人の場合、頻繁に変更を繰り返すと、覚えやすい単純なパスワードに収束していく傾向がみられる。


変更しろ、と言われたから、最初は 1234 に。次は abcd に…という具合に。

最初の設定ではそれなりに強度のあるパスワードを使っていたとしても、より弱いものに変えさせる「強制」は、百害あって一利なしだ。


(ちなみに、NIST の勧告では、abcd や 1234 といった「連続文字」パスワードは設定できないようにしなくてはならない、と示されている。

 これらは、ユーザーの利便性を最大限に考慮したうえでも、設定されるべきではないパスワードだ)



過去の記事に指摘をくださった方が「時間的な変更を促すと、パスワード管理が雑になる」と言っているのは、このことだろう。


同じ「時間的な変更」であっても、システムが強制するのと、ユーザーの自発性に任せるのとでは意味が違う。

この二つを混同してはならない。



強制はしてはならないが、時間的な変更はされるのが望ましいのだ。




話はこれで終わりだ。


NIST 勧告の「変更を強制すべきではない」はずいぶんと勘違いされていて、パスワードを変更してはならないのだと思っている人が増えているようだ。


強制すると雑になるから、というのは、ご指摘の通りだと思っていい。

多くの専門家がそう指摘している。


また、NIST 勧告では書かれていないものの、「わざわざ書かないだけ」で、前提にしている気がする。



一方、今回指摘を受けてネットを調査していたら、「パスワード変更の際に、変更しようとしているパスワードがネットワークを流れることになるから危険」と言う主張も見た。



変更自体が危険なのだと思っている人は、こうした話を「裏付け」として信じてしまうかもしれない。


しかし、たいていパスワードは暗号化通信(SSL)を使って通信されるから、覗き見られることはない。


「暗号化も破られるかもしれない」という前提に立つのであれば、ログインするたびに通信されるパスワードのほうが、変更のために1度だけ入れられるパスワードよりも、ずっと危険性が高い。


この危険度を下げるためには、同じパスワードでログインされる回数を減らせばよい。

つまり、時々パスワードを変更すべきだ。


結局、「変更の危険性」を主張しようとして変な前提を持ち出しても、むしろ変更すべきだという話になる。




さて、以下は余談。


わずか2週間前に、セブンイレブンが新しい電子マネーである「7pay」を導入しようとして、大失敗をやらかして、炎上した。


最大の大失敗は、システム側でのパスワード認証が「ざる」だったことだ。


本人の生年月日を答えられれば、任意のメールアドレスに対してパスワードの再発行を要求できる、というシステムがあり、生年月日を設定していない場合の日付初期値が固定だった。


このため、アカウントの ID さえ割り出せれば、高確率でパスワードを奪い取ることができた。

そして、ID は特に秘密ではない情報だった。


記者会見に応じた 7pay 社(セブンイレブンの子会社として電子マネーの会社が作られた)の社長は、報道記者から「なぜ二段階認証を使っていないのか」と質問され、「二段階認証って何ですか?」と基礎知識がないことを衆目にさらした。



パスワード管理の話としてはどこから突っ込んだらよいのかわからないところだが、二段階認証の説明をしたい。

すでに使っている人は多そうだが、これが何を目的としているのかちゃんと認識している人は案外少ないように思う。




二段階認証は、「パスワードは第三者が簡単に盗めるものだ」という前提に立っている。

簡単に盗めるから、 ID とパスワードの組を知っているから本人、とは単純に認証できない。



一方で、現代では、多くの人が携帯電話を持っている。

そして、携帯電話には電話番号がある。この電話番号は、本人と強く結びついたものだ。


そこで、アカウントに対してあらかじめ「連絡手段」としての携帯電話番号を登録しておく。

連絡手段があればよいので、固定電話やメールアドレスが使われる場合もある。



ID とパスワードの組での認証に成功した際、これは「第一段階」を突破しただけで、ログインにはならない。

ここで、「二段階目」として、サーバーから連絡手段を通じて何らかの情報(通常は6桁程度の数字)が伝えられる。


携帯電話番号に対してショートメッセージを送信、というように、この情報は「本人だけが受け取れる」ことが期待される。

そして、受け取った本人が情報をサーバーに伝え、正しい場合にやっとログインが完了する。



この方法は、


・本人にだけ伝えられる情報を利用するため、正しく本人であると確かめられる。

・万が一パスワードが盗まれた場合、本人に通知が行くため、パスワードが盗まれたことを知ることができる。


という2つのメリットがある。


特に後者は重要だ。


先に書いたが、パスワードが漏れて明らかな被害にあえば、パスワードを再設定するなどの対策がとれる。

しかし、通常は「ただログインされて情報を見られただけ」では気づかない。


二段階認証では、認証中に本人に通知を行うことで、第三者によるパスワード盗用が明らかになる。

これにより「見えない被害」を事前に「見る」ことが可能となるだろう。



ただし、大体のシステムにおいて、二段階認証は「オプション」扱いにすぎない。

携帯電話などを持っておらず「設定のしようがない」ユーザーもいるためだ。


そして、オプションを使わなければ、従来どおり、 ID・パスワードの組だけで認証が行われる。

認証自体は問題なく行われるため、二段階認証を使えるシステムであっても、これが何のためにあるのか理解できずに設定していない、という人は多い。


Google や Amzon, Facebook 、Apple、Twitter …etc,etc. 多くの有名サイトが二段階認証に対応している。

認証していないシステムでも、「Google アカウントでログイン」などが使える場合は、Google の二段階認証を「借りる」ことができる。


設定していない人は導入を検討してみてほしい。




しかし、実はこの方法での二段階認証は、強度的に十分ではないことがすでに分かっている。


携帯電話の電話番号というのは、携帯電話デバイスに固有のものではない。

購入してから、後付けで電話番号を「紐づけた」ものだ。


紐づけられるということは、別の人が別の携帯電話に対して、同じ番号を紐づけることも可能となる。

そして、携帯電話の通信網というのは歴史が古く、設計時には十分だと思われていたセキュリティがすでに破られていたりする。


つまりは、電話番号に対して送られたショートメッセージは、第三者によって「奪われる」ことがあるのだ。

奪われれば、本人にしか通知されないはずの情報は第三者にわたり、本人に通知されるはずの「第三者によるログインの可能性」通知も届かなくなる。


(注:海外と国内では通信方式も多少違い、破られているのは海外での話。とはいえ、類似方式で脆弱性が見つかっているのだから、国内でも過信は禁物)


メールアドレスに対する通知でも同じことがいえる。


固定電話は…本当の意味での「固定電話」なら、電話線に対して電話番号が割り振られている。

変更するには電話局内での設定が必要で、通信を盗むことは難しい。


しかし、今は「固定電話」といっても IP 電話であることが多く、これは後から機器に電話番号を割り振っている。

やはり過信は禁物だろう。



サーバーから本人に対して、「安全な通信経路が確保できる」というのが、この方式での二段階認証の前提だ。

安全な通信経路が確保できない場合、安全ではなくなる。




では、通信を行わないで、認証する瞬間にだけ使用可能な、本人だけが知れる情報で、サーバーに侵入されても情報が漏洩しない方法で、サーバーと秘密を共有すればいい。

そんなことできるの? と思われるかもしれないが、ちゃんとそうした方法は考案されていて、一部の二段階認証では選択できるようになっている。


ワンタイムパスワード、と呼ばれるもので、仕組み自体は結構古い。

2006年…いまから13年も前には、すでにジャパンネット銀行が導入している。


先に「パスワードは時間によって変更したほうが良い」と示したが、それを究極まで突き詰めたものだ。

30~90秒で、自動的にパスワードが変更されてしまう。これなら、万が一パスワードが盗まれても問題ない。


パスワードが変わってしまうと、本人すらログインできなくなりそうだ。

しかし、本人だけが持っているデバイスに、変更されたパスワードが示され続ける。


だから、本人だけはログイン可能だ。



ここで重要なのが、パスワードを示すのに通信などは不要だ、という点だ。

サーバーとデバイスは、お互いに示し合わせることなく、次々とパスワードを変えていく。


しかし、それらは時刻を基にした一定の計算方法で示されるもので、デバイスとサーバーで一致している。

計算で示される…ということはランダムではないのだが、たとえ計算方法を知っていたとしても、「鍵」がなくては同じ計算が行えない。


そしてここが一番肝心なのだけど、計算のための「鍵」は、デバイスの中にしかない。サーバーにもない。

だから、万が一サーバーに侵入され、情報を盗まれてもパスワードを知ることはできない。


この鍵は、公開鍵暗号を応用したものだ。

公開鍵暗号は、「公開鍵」と「秘密鍵」のセットを使い、秘密鍵で暗号化した内容は公開鍵でしか元に戻せない。


だから、デバイスが秘密鍵を持ち、サーバーに公開鍵を預けておくと、デバイスが作り出した暗号が「確かに正しい」ことをサーバーは確認できる。


公開鍵は、秘密鍵を基にして計算で求めることができる。

しかし、公開鍵を基にして秘密鍵を割り出すことは事実上できない。


だから、サーバーに預けた公開鍵を盗まれたとしても、それを基に秘密鍵を求めてワンタイムパスワードを生成する、ということができない。



13年も前に導入されたジャパンネット銀行では、6桁の数値を表示できる専用デバイスを配布してワンタイムパスワードを実現している。


しかし、今は多くの人がスマホを持っているため、スマホ上で同じ仕組みを作り上げたアプリも多数配布されている。

専用デバイスよりは気軽に導入できる。



ただし、専用デバイスの場合、パスワードを盗むことはできないうえ、デバイス自体を盗むと本人に気づかれる、という利点がある。


アプリの場合、スマホ内に格納された「秘密鍵」をコピーすることが可能であれば、同じパスワードを生成できるようになり、本人にも気づかれない。

そのため、アプリはセキュリティ強度が落ちることは知っておいた方が良い。


特に、スマホの買い替え時に「秘密鍵を新しいスマホにコピーできる」機能がある場合、便利だがセキュリティ強度は明らかに落ちる。


第三者に「コピーする」機能を使われれば、本人以外のログインが可能になってしまうためだ。

SMS を使った認証と異なり、本人に通知が行かず、不正ログインに気づくこともできないので、デメリットも大きくなってくる。



こうしたアプリによるワンタイムパスワード生成などで、ワンタイムパスワード導入のコストは下がっている。

どこのサイトでも導入できる状況は整ってきているけど、対応にはそれなりの手間が必要なため、対応していないサイトも多い。

これからは徐々に増えていくだろう。



しかし、現在のところ、こうした「安全な本人確認方法」に対応していないサイトは、まだまだ多い。


その点では、5年前の記事のパスワード管理方法は、依然として有効だ。

パスワードなんて不便なもの、早く不要になってくれればいいのだけど。



▲目次へ ⇒この記事のURL

同じテーマの日記(最近の一覧)

コンピュータ

歯車

関連ページ

パスワードの管理方法【日記 14/05/22】

別年同日の日記

02年 お祝い

07年 最近のうちの子

10年 這えば立て 立てば歩めの…

13年 海水浴

15年 ジェイ・フォレスター 誕生日(1918)

15年 厄介なバグ

16年 監視ユーザーの問題回避


申し訳ありませんが、現在意見投稿をできない状態にしています


戻る
トップページへ

-- share --

0000

-- follow --




- Reverse Link -