14
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

パスワードは 90 年代の代物だ(JSConfカンファレンス参加メモ)

Posted at

この記事はフューチャー 2 Advent Calendar 2019の 11 日目の記事です。
昨日は@Tetsu_minorityさんの記事でした。
Futureアドベントカレンダーはその1もあります!!ぜひご覧ください。

ごあいさつ

11/30、12/1 に開催されたJSConf JPに参加してきましたが、
たくさんのレクチャーがあり初めて知ることばかりでした。
今回はその中から、個人的に面白かったパスワードについてのレクチャーを
おさらいを兼ねてまとめてみようと思います。

Password is so 1990s(「パスワードは 90 年代の代物だ」) by Sam Bellen

「パスワード」の歴史

  • パスワードの歴史ははるか昔、古代ローマ人の時代にさかのぼる。
  • 10世紀ごろには「ひらけゴマ」という「パスワード」も誕生した。
  • 1961年にはタイムシェアリングシステムが登場。1台のコンピュータを複数人のユーザーでシェアして使うことができるようになった。
  • 1970年代には「ハッシュ化」の技術が生まれる。パスワードをよりセキュアに保存することができるように。
  • 1990年代には、ハッキングがより深刻な問題として顕在化した。

パスワードの種類

ところでパスワードとは何か

それは 秘密をシェアするすべてのもの のことである!

色々なパスワード

  • 意味のないアルファベットの並んだ文字列など、複雑なものは覚えられにくい。
    • つまり、複雑であれば他人から推定されにくい。
  • 一方でPINコードのように簡単なものは覚えやすい。
    • つまり、他人から推定されやすい。
    • よってPINコードなどは生体認証(などの複雑な認証)と合わせて使うとより安全である。
  • パターン認証は推定されにくいほどのものではない。
    • 覚えやすくはある。物の認証に使われる。

パスワードの問題点

  • 忘れたらリセットしなきゃいけない。
  • リセットの作業がとにかく面倒!
  • 手間を省くためにパスワードマネジャーを使うことになるが、パスワードが必要なサイトが増えるほどハックされる可能性も高い。

より良いパスワードにするためには

  • 複雑なパスワードにする
  • 個人情報を含めない
  • パスワードを再利用しない
  • 頻繁にパスワードを変更する

これらが有効だが、誰もそんなことしない。Sam Bellen氏だってしない。
そこで、

パスワードレスな認証

  • ワンタイムパスワード
    • 一度だけ使用できる。短時間で有効期限切れる。
    • ユーザーに直接届く。iOSやAndroidならば届いたメッセージから推測して入力できる。
    • 二段階認証が必要ない。
    • ただし:携帯が必要である。
    • メールで送信できれば問題ない?否、メールも解析される恐れがある。
  • 認証アプリ
    • 時系列だったり、プッシュ型だったりする。
    • アプリケーションと認証サービス間で秘密の情報を共有する必要がある。
  • SMS認証
    • 覚えなくてはならないパスワードが減る。
    • 信頼できるサービスにのみパスワードを教えるだけで良い!
    • ただし;他のサービスに認証を依存することになる。
  • 他の認証アプリも、二段階認証の一つとしてよく使われる。

Web認証API

webauthnというクールな認証APIがある

  • キーベースの認証である。
  • 認証はハードウェアで行う。
  • 新しいキーを生成し、保存するようになっている。
  • モダンなデバイスだと認証装置がビルトインになっている。(touch IDなど)

どのように動作するか?

  • クレデンシャル登録・・・一度登録すれば、いつでも認証できるようになる!

    1. 認証のリクエストがサーバーに送信される。
    2. レスポンス(「Challenge」と呼ばれていた)がデバイスに返ってくる。
    3. ユーザーがデバイスを操作する。(ChallengeにSignする)
    4. デバイスからサーバーへSigned ChallengePublic Keyraw IDが送られる。
    5. サーバーはユーザー名と一緒にそれを保存する。
    6. 登録完了
      image.png
  • 認証

    1. ユーザーがユーザー名をクライアントに入力する。
    2. ChallengePublic Keyraw IDがサーバーから返ってくる。
    3. ユーザーがデバイスを操作する。(ChallengeにSignする)
    4. デバイスからサーバーへSigned Challengeと、登録時と同じPublic Keyが送られる。
    5. 認証完了
      image.png

webauthnで嬉しいこと

  • ハードウェア認証なのでinternal、externalも分けられる。
  • ハードウェアを通しての認証なので、パスワードを入力する必要がない!

課題もある

  • ユーザーがクレデンシャルをどう管理するか
  • デバイスをまたいでのクレデンシャル発行
    • 紛失したデバイスの認証システムはどう復旧するか、など

それでも

  • webauthnはパスワードに取って代わるシステムとなるだろう。
    • (Auth0などの認証サービスの代わりにはならないだろう)
  • W3C勧告にもなっており、様々なブラウザが対応しようとしている。
  • GoogleやGithubではすでにwebauthnを使える!

所感

  • この発表によって、ログインにはIDとパスワードのセットが当たり前、という思い込みを打ち破られました。
  • 時代はクラウド!と言われる中でハードウェア認証なんだ、、と最初は戸惑ったが、物理的な認証であれば自分が持っている限り盗まれることはない=ハックされにくいという点では納得できる気もしました。

参考

14
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
14
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?