「ログイン状態を保存する」は通常何をしてる？

Question

様々なログインフォームがあるサイトでチェックボックスにチェックを入れて「ログイン状態を保存する」が出来るものがあります。

あれと同じものを作ろうとした場合、入力されたメアド、パスワードをクッキーに保存しておいて、ログインページが表示された際に、クッキーに保存されたメアド、パスワードがあったらセットするということをしているのでしょうか？

その場合、クッキーには生のパスワードが保存されると思いますが、クッキーは他の人がその人のパソコンを触れるなら見ることが出来る気がしますし、それでいいものなのか気になっています。

それとも、サーバ側でセッションの有効期限を無限にしてログアウトされないようにしてるのでしょうか？
それだとブラウザを閉じたらログアウトしてしまうような気もしますがそうではないでしょうか？

今どき、ブラウザやスマホの機能でパスワードを記憶してるからなくてもいいのかなという気もしないではないですが、ログアウトしないでずっとログインしていられるならそれもいいかなと考えています。

Answer 1

その方法は下記の本の5.1.4節「自動ログイン」にて解説されています。

5.1.4 自動ログイン
Webアプリケーションによっては、「自動ログイン」あるいは「ログイン状態を保持する」というチェックボックスがついている場合があります（図5-12）。自動ログインを有効にしていると、ブラウザを再起動しても、自動的に再ログインされます。
体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 より引用

以下については、

あれと同じものを作ろうとした場合、入力されたメアド、パスワードをクッキーに保存しておいて、ログインページが表示された際に、クッキーに保存されたメアド、パスワードがあったらセットするということをしているのでしょうか？

この方法は、上記の本にて「危険な実装例」として紹介しています

クッキーに秘密情報を保存していると、仮にこのサイトにXSS脆弱性があった場合、パスワードまで盗まれてしまい、被害を拡大することになります。このため、上記の実装は好ましくありません。

一方、下記の方法については、

それとも、サーバ側でセッションの有効期限を無限にしてログアウトされないようにしてるのでしょうか？

この方法は先の本の安全な実装方法の一例として紹介されています。

それだとブラウザを閉じたらログアウトしてしまうような気もしますがそうではないでしょうか？

そうならない方法も同書にて説明しています。

別法として、同書では「トークンを使う」方法を紹介しています。セッションの寿命を伸ばす方法は簡易法、トークンによる方法が本命というところですかね。

ということで、詳しくは書籍を参照ください。

Comments

[ar3qna]

ためになりそうな書籍を紹介いただきましてありがとうございます。

やはり生パスワード保存はよろしくないんですね。
セッションを無限にしつつ、ログインセッションにクッキーを使用し、クッキーのexpire自体をsessionでなくとても多い未来に設定すれば行けそうな気がしますね。

まずは書籍を読んでみようと思います。ありがとうございます。

Answer 2

その場合、クッキーには生のパスワードが保存されると思いますが、

どのサイトを参考にされたのか分かりませんが、ブラウザのCookie情報を見て生のパスワードが保存されいたのであれば、そのサイトはかなり危ないサイトかと思いますので使わない方が良いでしょう。

それとも、サーバ側でセッションの有効期限を無限にしてログアウトされないようにしてるのでしょうか？
それだとブラウザを閉じたらログアウトしてしまうような気もしますがそうではないでしょうか？

セッションやログアウトの概念をどうとらえてられるかによりますが、Cookieも使って含めて上手く実装すれば、「見かけ上」はそうはならないようにできると思います。

じゃあどうやってログインを実現しているのか？となると、ここでパッとお伝えできるほど簡単な内容ではないと思いますので、"cookie ログイン 実装"などで検索して、色々なサイトを見てみるといいと思います。あまり古い情報は参考にせずに、新しめのサイトで信用できそうな情報をみるようにしましょう。自動ログインは不正アクセスの温床になりますので、あまり自分で考えて実装しない方がいいかもしれません。

Comments

[ar3qna]

ありがとうございます。そうですね。フロント側でログアウト状態でもログインできる情報があったら自動ログインしてリダイレクトすれば見た目上はログアウトしていない状態にできそうですね。

確かに不正アクセスに使われそうな気がしまして、仕組みだけでも理解しておきたいと思っています。

Answer 3

ランダム生成したリメンバートークンをDBとクッキーに保存して比較している。
クッキーを暗号化していれば改竄されることはない。

こういう機能は自分で作らずフレームワークに任せる部分。

Comments

[ar3qna]

ありがとうございます。トークンを保存しておくんですね。

クッキーの暗号化というのは、ログイン時にサーバ側から暗号化したトークンを返すということなのか、セキュアモードでhttpsでクッキーやり取りしていたら、たとえクッキーを覗かれたところで、それをコピーして他のブラウザでクッキーを作って同じ値をセットしても使えないということなのでしょうか？

確かにフレームワークに任せるのが正解な気がしますが、理解だけでもしておきたいところです。

Answer 4

質問に対しての回答という意味では、「体系的に学ぶ 安全なWebアプリケーションの作り方」の著者の blog が分かりやすいです。

ログアウト機能の目的と実現方法 - 徳丸浩の日記

ログイン状態の反対ってわかります？そう、ログアウト状態です。
ログアウト状態ってどういう状況か？それを理解することで、ログイン状態を保存ってどういう状況なのかを理解することが出来ます。

ただ、古い記事なので実装に関しては、別途最近のトレンドを調査してみてください。
考え方が理解できていれば、適当に流行りのフレームワークやライブラリを覗くことでトレンドに追いつけます。

また、紹介した記事は体系的な情報ではなく切り取った話題なので、別途認証/認可全体として網羅性のある体系的な学習をされることをオススメします。

Answer 5

様々なログインフォームがあるサイトでチェックボックスにチェックを入れて「ログイン状態を保存する」が出来るものがあります。

あれと同じものを作ろうとした場合、入力されたメアド、パスワードをクッキーに保存しておいて、ログインページが表示された際に、クッキーに保存されたメアド、パスワードがあったらセットするということをしているのでしょうか？

認証システムによっていろいろ変わってくるでしょうが、ASP.NET で昔から使われているクッキーベースの認証システムの例を話します。

ASP.NET Web アプリでは Visual Studio のテンプレートで作る Login ページに以下の画像のように［Remember me?］というチェックボックスがあります。これが質問者さんの言うチェックボックスに該当すると思います。

上の Login ページでログインに成功すると、サーバーから認証チケットが認証クッキーに含まれて送られてきます。以降のやり取りではブラウザから認証クッキーがサーバーに送られるようになりますので、認証状態が継続されるという仕組みになっています。

その仕組みは［Remember me?］にチェックを入れる入れないにかかわらず同じです。では、何か違うかというと以下の通りです。

チェックを入れる

チェックを入れた場合は以下のよう expires によって認証クッキーの有効期限が指定されます。

Set-Cookie: .ASPXAUTH=...; expires=Wed, 30-Nov-2011 13:21:29 GMT; path=/; HttpOnly

Set-Cookie: に expires=...; が指定されている場合ブラウザはクッキーをディスクに保存します。

ブラウザを閉じたり OS をシャットダウンしたりしても、再度ブラウザを立ち上げてアクセスすれば、ブラウザは認証クッキーをディスクから取得してサーバーに送ります。

クッキーの有効期限が切れると、ユーザーが次にサイトを訪問した時にブラウザによって削除されます。

次回アクセスする際にログイン操作の手間が省けるということが「チェックを入れる」ことによるメリットです。

昔は 50 年もの有効期限が「チェックを入れる」ことにより与えられましたが、さすがにセキュリティ的に問題なので最近はデフォルトでは 30 分程度の短い時間になっています。

チェックを入れない

この場合、Set-Cookie: に expires=...; は付与されないので、認証クッキーはブラウザのメモリにしか保持されません。従って、ブラウザを閉じれば認証クッキーは消えます。

逆に、ブラウザを閉じなければ認証クッキーは消えません。要求のたびに送られ続けます。（ただし、中身の認証チケットが有効かどうかは別の話で、有効期限はアプリの設定によります）

【追記】

もう一つの疑問、

その場合、クッキーには生のパスワードが保存されると思いますが、クッキーは他の人がその人のパソコンを触れるなら見ることが出来る気がしますし、それでいいものなのか気になっています。

に答えてなかったですね。

上に書いた ASP.NET のクッキーベースの認証システムの場合ですが、パスワードは認証チケット/クッキーには含まれません。認証チケットの中身は暗号化されたユーザー名、ユーザーが属するロール、有効期限などです。

認証クッキーから認証チケットを取得し、それが所定の暗号キー、プロテクタで復号できて、有効期限内であればその認証クッキーを送ってきたユーザーは認証されます。

なお、パスワードはハッシュされてサーバーに保持されます。ユーザーから生のパスワードが送信されてくるのは、上に書いた Login ページでログインするときのみです。その生のパスワードをハッシュしてサーバーのハッシュされたパスワードを比較するようにしています。

Comments

[ar3qna]

ありがとうございます。とてもわかり易くて理解ができました。
クッキーのexpireをsessionにするのか、遠い未来にするのかの違いなんですね。
自前のjsで同行するのではなく、サーバ側の処理でセットするだけで行けそうですね。
ありがとうございました。

[退会済みユーザー]

> クッキーのexpireをsessionにするのか、遠い未来にするのかの違いなんですね。

そこを見ると私が上の書いたことを理解しているとは思えないのですが？　レスを読んでもらってます？　読んでも理解できないということですか？

サーバーから認証クッキーを送る際に、応答ヘッダの Set-Cookie: に expires=...; を付与するか否かの違いです。

「遠い未来にするのか」どうかというのはそれとは何の関係もない別の話です。