パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~
ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単！けどこれ指紋認証だけ？弱くなってない？ SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった？ この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする
不正ログイン発生時の "ユーザーの混乱や不安" を解消するための仕組み - 2023秋
ritou です。 XのTLを見ていたら、Amazonでの不正ログインについての投稿が目に入りました。 いざ被害にあってしまうと"2段階認証も意味ない"みたいな投稿をしてしまうほど、混乱してしまうものです。 混乱したり、不安になってしまったユーザーがサービスを退会してしまわないように、サービス側でできる仕組みを整理しておきましょう。 これまで何が起こったか、今どうなっているのかを確認できる仕組みを提要 これまでの啓蒙が実ったのか、被害にあって実感したユーザーが増えたからなのか、不正ログインが起こったらパスワードを変えるという意識は広まったようです。 2019年にQiitaに投稿しましたが、不正ログインが起こった際に必要なのはユーザーが正しく情報を知ることができる仕組みです。 何が起こったのかを知る : セキュリティイベントログ 今どうなっているかを知るしくみ : ログインセッションの管理
"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
