#39.5 @kokukumaさんと認証認可等について語る回

エピソードの導入

こんばんは、Replay.fm 第39.5回です。

こんばんは。

えー、.5って何ですか?

早いね、えーっと…

いや、ほんまに早いのか。

早くないわ、確かにね。

.5、はい、.5っていう、なんと夢中単派な数字なんですけど、

今回はいつもの記事を読む回とは違う話をしたいなと思っていて、

具体的にはまあ、認可について話したい、認可ないしはパスキーとかについてしゃべりたいですけど、

まあ、あの、何でしょうね、まあ僕らだけでしゃべっても別にいいんですけど、

せっかくなら詳しい人にいろいろ聞いて勉強させてもらおうということで、

今日はなんと初のゲストを呼んでおります。

わお、すごい。

はい、なんで、あの、コッククマさんという方をね、お呼びしてるんで、

ちょっと一言いただいてもいいですか?

すごい雑に、振り慣れてないな、お願いします。

こんばんは。

コッククマです。よろしくお願いします。

お願いします。

コッククマさんは何をやってる人なんですか?

コッククマはですね、今メルカリの認証とか認可を使っているチームで働いてます。

すごい、あのメルカリで?

あの、まあ、どのメルカリかちょっとわかんないですけど、あのメルカリです。

かの有名なメルカリで。

なんで有名かはちょっとわかんないですけど。

あー、認証認可をやってらっしゃるコッククマさん。

大勢になってますからね。

いやー、こんななんか超マイナーボッドキャストに来ていただいてありがとうございます。

まあ、メルカリの知名度って書いてたらマジで天と地ほどの差あるもんね。

まだまだね、頑張っていかなきゃって感じなんですけど。

いやー、ありがとうございます、本当に。

ヤギ足が一緒に働いた経験がある?

いやー、もうズブズブですよ、ズブズブ。

ズブズブの関係ですね。

あー、ズブズブの関係ですよ。

いやー、その縁があって。

雨の日も風の日もなんか一緒に認証認可について考えた、ズブズブのお宅ですね。

なるほどね。

まあまあまあ、なんかちょっと突っ込みたくなったけど、置いといて。

いいんだよ、いいんだよ。

いやいや、いいっすよ。

本筋が揃えることあんまり言わないように頑張ってたんですけど。

僕は、そう、収録前にちょっと話しましたけど、

たぶん一瞬被ってたみたいな感じで、なんか存在は認知してたが、話すのは初めてというか。

そうですね。

はい、そんな感じでね。

元メルカリ三人集でお送りします。

パスキーの利点と課題

あれ、元じゃなくない?

ここが元じゃないよね。

新旧は、新旧メルカリ三人組。

ちょっとなんかその、別に、やめるとかじゃないですよ。

やめない、やめない。

まだまだやめないです。

カットしなきゃいけないです。

やめないです、やめないです。

まだ、まだやめたい。

まだ、まだやめないです。

いつかはね。

人なんで。

やめる可能性ある。

じゃあ早速なんか、パスキーとか認可の話をできればっていう感じなんですけど、

事前になんかいろいろこういう話を聞きたいみたいなのはちょっとプロットを書いていて、

これもコンローションもまあ多分配信と合わせて公開すると思うんですけど、

パスキーの話からします?とりあえず。

うーん、しましょうかね。

なんか、こくくまさんは、なんか、まあパスキーのプロだと思うんですけど。

そういうことにしちゃいましょう。

こう、なんか、まあぶっちゃけパスキーってどうですか?

うーん、どうか。

まあ、なかなか、うーん、こう、あ、ちょっとここに貼り忘れてたけど、

なんか、あのー、あれですよね、1000万人突破したんですよね。

あー、メルカリー、そうですね。

あー。

うん、あ、記事出てるじゃないですか。

こくくまさん持ってなくない?これ。

そうです、僕はあんまり貢献してないんで、ちょっと、そこには参加できなかったです。

ははは、ウケる。

あ、写真家なんかが載ってるってことですか?

いや、貼っといたわ。

あ、ほんとだ、これか。

うん。

えー。

えー、ウケる。

あ、ありがとう。

はい、まあそんなメルカリーでパスキーを導入してるこくくまさんなんですが、

なんか、まあこのPodcastで、このPodcastの普段のその、なんて言ったらいいんだろうな、

えーっと、流れというかやってることみたいなのをさらっと紹介しておくと、

えーっと、普段は1週間、あのー、セキュリティ関連の記事を読みためて、

えー、それを、まあ2人で持ち寄って、えー、お互いになんか読みたかった記事とか、

えー、読みたかった記事?読みたい記事?

あの、ピックしたい記事を、そうそうそう。

持ち寄って、えー、まあここで紹介しつつ、なんか、まあ、なんて言ったらいいんだろうな、

健全な飲み会ぐらいのノリで、なんかあーでもないここでもない喋って、

あの、うだうだやってるようなPodcastなんですけど、

えーっと、まあ割となんていうかパスキーの話題って、

まあちょっと最近減っちゃったんだけど、なんかAIに加わりまくってて最近は。

うん。

あのー、ちょっと前はなんか割とパスキーの話題ってすごく多くて、

あのー、まあ端的に言って結構パスキーしんどいっていう話が、

なんか、割と、まあよく見受けられた。

で、まあそういう中で紹介した記事もあれば、紹介してない記事もあったりするんですけど、

えーっと、なんて言ったらいいんだろうな、なんか、

まあちょっと1個ずつ記事をちょっとさらっと漁っていきますか、そしたら。

うん。

なんか、割と多分思い出す中で一番その印象に残ってて、

かつ、まあその中でも古いものっていうのが、この、

Passers Has Problems, But Paskis Has Moreっていう記事。

うん。

で、これって覚えてますか?

多分読んだことあると思うんだけど。

読んだことありますけど覚えちゃいそう。

うーん、なんか端的に言うと、

でもほんのすごく大雑把にまとめると、

なんか、まあ知り合いだかなんだかが、その、なんかパスキーですげえ困っててみたいな。

で、クロスプラットフォームのそのログインでめっちゃコケてて、

なんか、まあパスキーしんどいよね。

なんか、まあパスワードがダメならわかるけど、

なんか、そのこのパスキーをまともに使えるように、

その誰かに説明するよりもパスワードマネージャーの使い方を教えるほうが全然楽だよね。

はい。

主張を書いてるような記事。

うん。

この辺ってなんか今もあんまり変わってないんですかね?

クロスプラットフォームとかハイブリッドトランスポートとか、なんか。

そう。

その辺の事情というか。

なんか各プラットフォームによっては、

たぶん例えば、クロムを入れておいたらクロム間で

どのOSまででもパスキーシンクできるみたいな話が出てきたりとかして、

それぞれのプラットフォームで結構、

うまくシンクできるようにさせるっていう方は進んでいると思うんですけど、

プラットフォーム間でクロスデバイスをうまくやる、

パソコンのUXを改善するっていう動きはそこまで大きく変化はない気は、

僕の観察ではしてますね。

なのでパソコンのUXに問題がある、

あの難しさっていうのはそんなに変わってないと思います。

そうですね。

ハイブリッドトランスポートの現状

っていう中で、

そうするとユーザーとしてそこをまたぐのに一番便利な方法って何になるかなってなると、

パスワードマネージャーとかの、

いわゆるサードパーティーのパスキープロパイダーを使うっていうのが

割と選択肢として入ってくるかなと思うんですけど、

サードパーティーって何に対してのサードパーティーなのか、

まだ僕は腹打ちしてないんだけど、

例えばGoogleとかAppleとかマイクロソフトとかが提供してる、

そういうのがパスキープロパイダーとして振る舞うのに比べて、

サードパーティーのパスキープロパイダーって強みに弱みみたいな、

強みはクロスプラトーンとかでかなり動かしやすいよねって話があると思うんですけど、

弱みとかってあったりするんですか?

弱みですか。

RPがうまく実装してなかったら使えなかったりするっていうのはありますよね。

どっかのRP、すごく身近なRPでも使えたり使えなかったりしてたりするので、

そういうのもあるかもですね。

なんですか、目で始まってみて終わりかなと。

かもしれないですね。

RPはリライングパーティーの略だね。

そうですね。

なんかRPって自然に言っちゃいますけど、

RPはRP。

結構ハッキーなことやったりするから、

結構微妙なところがあったりするんですよね。

動作に使うときに。

なるほどね。

それをオーバーライドして、

サードパーティーパスキープロパイダーに。

あれってなんかRP側からサードパーティープロパイダーを許容するかどうかって、

制御できたりするんですか?

いやー、呼び出す方は制御できない。

なんかどの辺が、

どの辺がハッキーなんですかね。

JavaScriptのWebAuthのAPI呼ぶじゃないですか。

で、普通に考えたらあれ、

Platformのやつ呼ばれるんですけど、

結構サードパーティーパスキープロパイダーのプラグインとか入れておくと、

あのWebAuthのAPIをオーバーライドして、

サードパーティーを呼び出して、

で、呼び出して、

あのやり方自体はもうRPから制御できないから。

なんかユーザースクリプト的な動き方をしてるっていうイメージなのかな。

そうですよ。

あー、なるほどね。それはだいぶ気になりますね。

なんか、

あー、なるほどね。それはだいぶ気持ち悪いな、そう言われると。

なんで基本的にこの考え方としてのかな、

RPにその辺の制御は基本的にはできない状態だと。

パスキープロパイダーを選ばせないっていう。

はいはいはいはい。

えー、面白い。

なんかその辺の実装ってまだ自分でちゃんと手動かしてなくて、

なんか、

結構透過的にその辺はやられてるものだと思ってたから、

なるほどね。そんなトラップがあるんですね。

自分たちなんかすることは特にないんですよ。

まあまあRP自体やれることない?

RP自体はないです。

ユーザー視点動く、ユーザー視点動く動かないはあるから。

それは困っちゃうんだけど。

えー、なるほどね。

なんかそれに対してじゃあハイブリッドトランスポートはどうなんですか?

っていうと、

サードパーティー関係なくてどうですか?

まあ要は、

サードパーティーも例えばしんどいねっていうシチュエーションにおいては、

じゃあハイブリッドトランスポートするかっていう話になると思うと。

そうですね。

ちょっと本当にこの話は僕の意見っていう感じなので、

別にファイドアナウンスとか何の関係もない話なんですけど、

正直、

ハイブリッドトランスポートプラスデバイスの話って結構、

一般ユーザーには難しいんじゃないかなって思って。

結局パースキーのメカニズムとか、

どこにパースキーがあります?

今自分が管理してパースキーがどこにありますか?とか、

そもそもいつ作られましたか?とか、

なんかそういうようなことを意識してないと、

あれ結構使いにくいと思うんですよね。

なので、

ファイドアナウンスとしては、

UXを改善していきたい、

どうやったらユーザーがうまくパースキーを使えるようになるかという方法を考えていくスタンスだと思うんですけど、

多分1RPからしてみると、

多分極力使わないような実装にした方がいいんじゃないかなとか思ったりはしちゃいますよね。

なので、RPによるんですけどもちろん。

パースキーとパスワードを併用してもいいよね、RP。

要はUX改善とか、

SMSOTPのポスト削減を目的にパースキー導入してますってとこだったら、

パスワードとパスキーの選択

別にパスワード削除する必要性ないんで、

パースキー使えるんだったらパースキー使うし、

使えないんだったらパスワード使うっていう、

要はフォールバックとしてパスワードを持っておくって、

そうしたらクロスバイト使う必要ないじゃないですか。

だからそっちの方向に落とした方がいいんじゃないかなとは思ったりしますね。

なるほどね。

今のところは。

SMS節約パターンとかそういうパターンもあるんだ。

ちょっと本題じゃないかもしれないけど。

そうですね。

パースキー導入するとき、

大体3つぐらいモチベーションあるかなと思って、

例えばフィッシング対策のためにパースキー導入したいっていうのと、

SMSOTPのコスト、結構かかるんであいつ削減したいっていうモチベーションと、

あとは基本的なログインのUX、認証のUXを上げたいっていうモチベーション、

大体3つかなと思って。

なるほどっすね。

確かに。

自分がそのコスト管理したことないから、

知らないだけでたぶん、それこそ目で始まっている、

理科、リードワールド、

馬鹿にならない金額かかってそうな。

まあね、うん、すごかった。

多分課題もできるもんね、いつ、NAとしてとかね。

うんうん。

まあイニシャルの最初のMFA作ったときは、

本当にいつ、いくらで、

ログインがこのスパンで何件かから、

いくら増えますねみたいなのを出したし、

実際結構かかる話ではある。

積極的に周りは珍しく費用対効果が出る取り組みなのもあるし、

捉え方にも。

まあね、一方ででも、

3Dセキュアにおける過豪値みたいなのに近いと思うけど、

それで離脱していくリスクっていうのもやっぱりあって、

いろんな意味で、

まあでも別に費用対効果に影響しないものって厳密に言うと

多分なくて、

SNSの送信コストみたいなのは、

分かりやすい例ではある。

全然、ステークホルダーから見たときに分かりやすい系だなと。

でも一方でさ、

だからじゃあ全部パス金にしろよって、

ランボリ言われてしまっても困るから。

そうだね。

だからって言って、

じゃあパス金がダメならメールでいいじゃんって言われても、

フィッシング対策の重要性

それはそれでまた困ってるし、

難しいところではあるんだけど。

パスワードも併用すればいいじゃんっていう話もある一方で、

結構この、

パスワードそのものの振動さみたいなのも一定あると思っていて、

そもそもパスワードマネージャーを使ってもらうとかって、

サービス提供者視点では強制できないじゃないですか。

その辺って、

すごいトーンが厳しくなった。

トーンが厳しくなった。

アメリカ人の中でも話してた中で多分察してる部分はあると思うんだけど、

割と過激派というか、

割と過激派だと自分では思っていて、

農場にもあったけど、

テペエスさんが投稿してた、

このパスワードが、

パスワードは問題があるが、パス金はもっとある。

の記事に関連してテペエスさんが投稿してた、

パスワードマネージャーを使わせるっていうのが無理だよねっていう話は完全に同意するところで、

なかなかサービス提供者視点として、

実際にユーザー保護のために何ができますかってなった時に、

事実上パス金一択じゃないっていう風に、

技術的に確実な方法ってもうそれしかないよねって思っていて、

その辺の苦しみとかってどういう風に考えてるのかなっていう話をぜひ聞いてみたかった。

そうですね。

まずパスキープロバイター、

パスワードでいいじゃん、パスキープロバイター使わせればいいじゃんみたいな話は、

分かるんですけど、

やっぱ言われてたように強制する方法ないし、

強制するとなったらそれパスキーだし、

基本的に守ろうとするとパスキーになっちゃうなっていうのはありますね。

一方で守ろうとした時にやっぱりパスワードがウィーキャストリンクになるので、

そこを消さなきゃいけない。

でも完全に消すとクロスデバイスの苦しみがまた発生するっていうような状態になるので、

何かしらフォールバック、オルタネティブは、

オーセンリケーションは、

RPのセキュリティレベルに応じて準備すべきだろうなっていう感じですね。

本当にサービスが求めているフィッシング体制のレベルが、

パスキーと同等レベルが必要なんだっていう話だったら、

もう仕方がないので、

例えばiナンバーカードを使ったアイデンティプルフィングを持って、

アイデンティマッチングしてカバーリさせるみたいな方法を取らざるを得ないって思うんですけど、

例えばそこまでのレベルを求めてるわけじゃなくて、

パスワードプラスで攻めそうTPみたいな、

今のリアルタイムフィッシングアタックで容易に持っていかれるような印象要素は避けましょうぐらいのレベルだったら、

じゃあフォールバックとして別にフェデレーション使ってもいいし、

もしかしたらEmailマジックリンクプラスSSOTTPとかやってもいいかもしれないし、

なのでサービスのセキュリティレベルに応じて、

パスキー以外に何が使えますかっていうところを考えるところが、

パスワード削除、ユーザー守ろうとしたときに重要になってくるところじゃないかなっていう気はします。

未来のログインシステム

なるほどね、その辺の話をまさに触れてるのがこのファイダー・アライアンスのホワイトペーパーなんですよね。

The Journey to Prevent Physical Attacksっていう。

そうですね。

仕事でちょっと具体的にはめちゃくちゃ話せないんですけど、

まさにこの事業上求められるセキュリティレベルと、

完全パスキーにしたときにトレードオフみたいなところのバランスを取らなきゃいけないみたいな議論をしたことがあったんですけど、

今おっしゃったような、

パスキーと同等レベルを求めるならこうやりましょうみたいな。

ただ、そこまで求めないんだったらっていう、一番下がどこかわかんないですけど、

ある程度のレベルから最高レベルまでのグラデーションがあると思っていて、

そのグラデーションの中でどこを選択するのが正しいのか、正しいというか正解はないと思うんですけど、

どれがよりサービスによってベタなのかみたいなところを選ぶのって結構難しかったなと思っていて、

反省としてはちゃんといろいろ理解した上で、今もっかい望めばもうちょっといい議論ができたかなと思いつつ、

でも結構難しいなと当時思ったし、

現場で働いている人で同じように難しいと感じている人はいそうだなとか、

もしくはそもそもちゃんと理解せずに結構意思決定をしちゃったりしているパターンも普通にありそうだなみたいなところもあって、

たぶん難しいのは、何が一番難しいかというと、

新しいパースキーという認証要素を入れました、そのフォールバックとして別の新しいものを入れますかって言われると入れれないんですよね、たぶん。

なぜならパースキーですら登録してもらうのに苦労している状態なのに、

それのフォールバックとして新しい、例えば別のソーシャルログインを投入してそれを登録してもらえますかって言われたら、

誰も普通にしないんで、やっぱりそうなるとフォールバックとして使えるものって、

今現状使っているものの中から選択するという感じにどうしてもなっちゃうんですけど、

それが本当にセキュリティレベルとして、求めるセキュリティレベルに合っているのかって言われると、わからないという状態になっている。

しかも不都合な真実としてあるのが、パースキーを本当に使ってもらいたい層にアプローチしたいんだけど、

そういう層ほどその辺のリカバリ手段みたいなのをちゃんと用意するっていうのが、

言い方悪いけどあまり上手じゃないし慣れてないっていうのがあると思っていて、

そういうの綺麗にやれる人ってたぶんそもそも元々パスワードマネージャー使ってたりとかするし、

おおむね別にパスキーなしでも安全に暮らせてる人たちなはずで、

その辺は結構不都合な真実としてありそうだなってちょっと思ったな。

あとは、ちょうど先週、先週じゃねえや、昨日か、昨日話した中にもそんな話があったよね。

マイクロソフトの調査で。

Googleの調査ね。

Googleか、これだね、ちょっと貼っときますけど、

そうそうそんな記事があって、このZ世代は割と他の世代と比べると割と優位にパスキーとかに慣れてるよみたいな話とかもあったりとかして、

でも全然優位にって言っても2ポイントとかそれぐらいあったんだよね確かね。

せいぜい多くても40%みたいな感じだった気がするから。

Z世代で40%だったかな。

40もいかないんだっけ、あそうだよね、これだよこれこれこれ。

Z世代が40%か。

そうそうそうそう。

なんかね、割とこう、なかなかね、これをだからパスワードマネージャーとかをさ、

パスワードマネージャーとか使ってる割合を、パスキーを使ってる人たちの割合が優位に超えてくるような時代にならないと、

多分パスキーでめちゃくちゃフィッシング防げてますみたいな時代にならないと思っていて、

なんかなかなか世知辛いなみたいなことを思ってたりする。

いやー、なんか1、サービス事業者という立場に立った時に結構難しいな。

そうだね。

っていうのはさっきのRPには何もできないみたいな話は多分真実で、

じゃあ本当にパスワードマネージャーを強制させるみたいなことができるのって、

多分ブラウザを作ってる会社とか、あとはOSを作ってる会社とかなのかな、場合によって。

なので、Chromeとかはいろいろアップデートがあるじゃないですか。

そうだね。

知らずにパスキーが作られるとか。

iOSもなんか似たような仕組み。

ロエパスワード勝手に変えるとかね。

勝手には変えないけど、ワンクリックでワンポツで勝手に変えてくれるみたいなやつとかね。

そっち側、現実的にはそっち側がカワレッジを広げる方が早いのかなという気もしつつ、

でもそれに乗るためには結局事業者側がパスキー認証をサポートしてなかったら乗ることはできないから。

でもパスキーでさ、例えばGoogleとかAppleとかMicrosoftがめちゃくちゃアイデンティティを握るっていう時代になってきた。

今、別にブラウザに何らかのアカウントでログインしてる状態だったら、

別に新たにログイン画面とかを通らなくてもどこでも普通に通っていけるみたいな世界になってもおかしくない気がするよね、それで言うと。

なるほどね。ログインの概念自体がもう。

みんなどこもおかしくGoogleのアカウントとかiMessageのアカウントとかAppleのアカウントとかで登録されるようになっていて、

そこの横の繋がりは必要なんだけど、ブラウザにそれらのどれかのアカウントで入っていればログイン画面とかは通らずに、

そのままスッとユーザーが識別されてっていう世界になっても別におかしくないような気もするし、ここまできたなら。

なるほどね。

それは結構若干話ずれますけど、アジェンティックAIの世界に近いかもしれないですね。

結局、アジェンティックAIとかオペレーターAIみたいなやつだと、やっぱり一つのコンソールとかUIからいろんなサービスにつなげに行きたいわけじゃないですか。

ただそのいろんなサービスにつなげに行くにあたって一つ一つアカウントの作成が必要ですみたいになると、めっちゃ使いづらいしそこがボトルネックになるじゃないですか。

それで言うと、明示的にアカウントを作るっていう、一つ一つがアカウントを持ってるっていうよりも、

TIDじゃないけど、違うところにあるアカウントを使ってアクセスできるような状況にするっていう方がうまく使えるような気がしますね。

何ならそういう世界になってほしいな。別にここ使いますか同意するポチッとしたら必要な情報がGoogleとかから提供されていって、

別に自分ではパスワードも登録する必要ないし、パスキーも意識する必要すらなくて、ローカル認証で何か出てくるっていうのは当然あるだろうけど、

そういう世界になってくれたらいいなとは思うな。

エージェンティックAIの進化

もっと言うと、エージェンティックAIとブラウザの統合みたいな世界も多分あると思っていて、

今ローカルでカーソルとかクラインとかが動いてるようなものも全部ウェブブラウザに統合されていって、

ウェブブラウザ上のアイデンティティを使ってAIが何かいろんなものにつなぎにいくみたいな世界になってもいいような気がするし、

どういう世界になっていくのかわかんないけど、そういうのもありそうな気がするよね。

ChromeがいろんなMCBを叩くとかも全然あるのかもしれないし。

今の進化の速さを考えると全然非現実的じゃない気がする。

なんかもう来年ぐらいに出てきそうな気がするから、もう怖いよ、なんて怖い。

マジでやってそう。

そういう中でFirefoxとかは本当に生き残っていけるのかなってちょっと思ってたけど、あまりにもテーマが離れすぎちゃうな。

あとはさっきのアカウントリカバリーの話とかでちょっとふと思い出したんだけど、

このJackさんのレスパスワード時代のアカウント防災訓練の記事をめっちゃ思い出してて、

どこまでなくしたら自分はあらゆるアカウントを復旧できなくなるのかみたいな考え方って地味に大事になってくるなと思っていて、

例えばマイナンバーカードであればリカバリーできるよっていうサービスがあったとして、

じゃあマイナンバーカードなくしたらどうする?

ある日全てを失った時にどうやって自分のGoogleアカウントまでたどり着けばいいのかとか、

そういうのをちょっと思い出したりとかしてて。

なんかやってますか?

まさかいけない。

可能性の範囲です。

まさかいけない。

僕はこれを見てパスワードマネージャーのリカバリーコードのドックタグを作りました。

確かJackさんは何してるんだっけ?

ドックタグ作っちゃいました。

今もそうなんだっけ?

あれ違ったっけ?

いろんなところに分散しておいてるって書いてなかったっけ?

ドックタグはやってないんだっけ?忘れちゃったな。

でもドックタグの話は出てた気がする。

出てたよね、そうそうそうそう。

これは面白かったんだよ。

あ、これか。

シークレットキーを刻み込んだドックタグを作り、防災カバーに取り付ける。

それそれそれ。

一番でかくて悲壮そうな家電の一箇所に刻み込んでおく家族もしてる。

実家とか一緒にセッションできたデバイス置いておけた方がいいかなって。

そうそう。

でもこの全て失ったら結構、

これもある種のリスクコントロールの話で面白いなって。

冗長構成。

そうそうそうそう。

どこまで失えるかみたいな。

僕はもうセキュリティキーいくつか持って、いくつかのサービスに登録してますけど、

全部同じところに入ってますから。

しかもセキュリティキーって結構しんどくて、どれがどこに登録してあるのかわからなくなりませんよね。

マジしんどいんだよな。

そっか、複数持ってるんですね二人とも。

僕一個しか持ってないから。

家用と持ち歩き用とあるね。

分けてるんだ。

確かに不便か。

行っちゃうと家用はね、家のデスクのUSBのドックに刺さるようになってる。

家で作業する分にはセキュリティキーポチって通せるようになってる。

ちなみに僕は何もやってないです、これ。

この記事読んでやろうかなって考え中ではあるけど、まだ実行になるとしてます。

やりましょう。

タトゥーとか掘ればいい。

それこそ家事にあったら二度とアカウント復旧できない。

あれだよ、頭剃って、頭に入れて髪生やせば見えなくなる。

そこもやられてたら死んでるだろうみたいな場所に。

後頭部に書いといてさ、自分で見えなくして。

俺アカウント復旧するたびに剃るの?

そう。

剃ってたらアカウント復旧したなって。

しかも入るまで丸見えなんでしょ。

そう。

脆弱やな。合ってんのかそれ。

ありかもしんない。

何かの都合でセキュリティキーが変わる時代になったら。

一回黒染めのタトゥー入れてまた。

タトゥーそんなできるの?

シークレットにはできない。

シークレットキーにアクセスするための何かをタトゥーで入れといて、

それはコントロールできるようにしておいて、

で、シークレットキーは可変な状態にしておくべき。

それでいこう。よし。

決まりました。

何かこのポッドキャストの100回規定ぐらいでやる?

ちょっと考えておきます。

いいよ考えなくて。

ジャンケンで負けたほうがいいの?

嫌だよ。まず剃りたくないよ。

しかも俺ドックタグ作ったし。

そんなことを思い出したりしてましたね。

あとはこれはもともと貼ってた記事なんだけど、

パスキーとセキュリティの未来

結構パスワードマネージャー使ってれば大目で安全だよねと言いつつ、

結構やっぱり限界もあるよねっていう話が過去読んだ記事の中にあって、

メールチンプっていうメーリングリストのサービスの、

この人確か運営者なんだよね?

いや、えっと、あの、あっと反省した。

パスワード漏洩のサイトの運営者の人。

そっか。

ハバイピンパウンドの運営者がこのメールチンプを使ってメーリリスト運用してた。

そのアカウントが侵害されたって話。

そうそうそうそう。

結構すげえ疲れてるシチュエーションで、

パスワードマネージャーが自動補完してくれなかったんだけど、

もう超疲れてて、全然わけわからん状態で、

なんかぽちぽち自分でパスワード入れちゃって、

パスワードマネージャーから。

で、結局乗っ取られちゃいましたよと。

ログインした瞬間に、うんって気づいたんだけど、

全然間に合わなかったと。

いろいろやられちゃったよっていう話があって、

やっぱり人間がそこをコントロールするのって無理なんだなって。

これ読んで。

HKSであるんだけど、無理なんだなっていうのを思い出したりしてた。

ハバイピーポンドを運営するような人でもやってしまうっていうのが、

一ついう限界感はね。

なんか結構、その点パスキーって結構堅牢ですよね。

あれってアドバーサリー・イン・ダ・ミドルみたいなのって、

技術的には成立し得る?

難しいと思う。

基本的には無理ですよね。

RPIDでしたっけ。

あれが偽装できない限りは、たぶん成立しないですよね。

そうですね。

メインのっとられたりしたら、実行される可能性はありますけど。

のっとりの単位って、例えばサブドメインテイクオーバーとかでも無理ですよね。

実現しないですよね。

サブドメインは。

設定によるのかな、サブドメインの場合は。

できるのか。

そうするとサブドメインテイクオーバーとか結構今後ホットな話題になってきたりするのかな、もしかしたら。

そうかもしれないですけど、たぶんどっちかっていうと先に

パスキープロパイダーの方がやられるんじゃないかなっていう気はありますね。

そこを落としたらなんかいっぱいパスキーもあるんだから。

各RP落とすよりもパスキープロパイダー落とした方がっていう感じがします。

そうすると昔からある議論として、パスワードマネージャーにTOTPを保存するのはありかなしかみたいな論争ってありますよね。

パスワードと一緒に。TOTPもそこにあるから。

そうそうそうそう。

同じノリでパスキーをワンパスワードとかビットワーデンとかに入れちゃってるけどいいんだっていう話と、

あとこないだワンパスワード触っててびっくりしたんだけど、シェアードボルトにパスキー入れられるんですよね。

そうなんですね。

びっくりした。

それ入れてどうなんですか?入れて別の誰かにシェアする?

入れればアクセス持ってる人は使えるパスキーになるって感じですか?

そうそうそうそう。びっくりして。

結構頭の中でパスキーとローカルの認証が一対一対応してるっていう理解が頭の中に結構あったから、

シェアードボルトにパスキー入ってて、うん?みたいになってる。

でも要はそれってパスキープロバイダーの中の別アカウントに対してパスキーシェアするってことで、

それともにAppleのAirDropでパスキー誰々にシェアするのと変わりないっちゃ変わりないって話ですね。

最初はすごい気持ち悪くて、ありなのこれってちょっと思ったんだけど、

最終的に結局TOTPとか共有するのと大差ないなって。

かつブラウザレベルでドメインのチェックとかが入るからええんちゃうっていう気持ちに自分の中で落ち着いた。

パスキー自体はちょっとプロトコの名前忘れましたけど、

ファインダーナイズでもパスキープロバイダー間で安全にパスキーをやり、

インポートエクスポートして。

なんだっけ、クレデンシャルマネジメントAPIの中の一機能みたいな感じでしたよね。

なんかありましたよね。

クレデンシャルエクスチェンジ的な。

なんとかクレデンシャルエクスチェンジ的なやつがあったね、確かね。

基本的に一つのプラットフォームにロックインされるような状況を避けてる状態には悪い。

そもそもパスワードマネージャーに登録できるのにパスワードマネージャーからエクスポートできなかったら普通に困るからな。

パスワードとか全部エクスポートできるのにパスキーだけエクスポートできませんとか論外だし。

エアドロップでパスキー共有できるのを地味に今初めて知った。知らなかった。

それと言う理論、大丈夫なのって話は出てきたりはしますけど、

エアドロップだったらBluetoothの範囲内ですし、それで言ったらハイブリッドだと同じじゃんっていう感じがするから。

確かに。

いいだろう。

この議論一回、パスキーじゃなくてTOTPで一回社内で、仕事で議論したときには、

赤点事例のスタンスとしては良くないのかもしれないけど、

2FA登録されてないよりはマシだよねとか、

失われるよりは誰かの端末に紐づいちゃってて、その人が退職して失われるみたいなケースよりは100倍マシだよねっていうので、

腹打ちさせてたというか、そういう話をしたりしてた。

でもそれ真の意味での。

結局今の一番弱いところはパスワードのどの道。

まずはそこ消してからじゃないですかね。

次のターゲットで。

真の意味での別に2FAじゃないよねっていうのは、

指摘としては完全に同意してしまうな。

便利すぎるからパスワードマネージャーとかにそういうの入れないっていう選択肢がもう、

自分の中でもなくなっちゃってるけど、

ポーズとしての2FAの利用みたいな感じではあるよね。

ただ2FAかどうかよりフィッシング体制があるかどうかのほうが今現時点では重要な気がしますけどね。

フィッシング体制のあるものとしてパスキーを使ってるんだけど、

実体としては1パスワードのシェアドボルトにパスキーが入っていて、

その1パスワードのボルトへのアクセスはIDとシークレットキーとパスワードだけでできるから、

基本的には知識認証だけだよねみたいな。

そういうのもいいですね。

1パスのフィッシングサイトがめっちゃ流行るとかそういう世界ですよね。

今もあるのかな、見たことないけど存在は済むのかな。

1年ちょい前ぐらいにラストパスってあった気がする。

ラストパスはね、あれは多分シンプルにお漏らししてた。

あれに侵害されたのか。

なんかね、多分間違えて置いちゃってた系の、公開しちゃってた系のやつだった気がするけど、

どっちだっけな、侵害じゃなかった気がする。

ありましたね。

でも1パス使えるの良さはフィッシング引っかかりづらいみたいなのが今時点だと思うのかな。

まあね、傾向としてはなくはないと思うけどね。

そのワンステップどうしても入るからさ。

まあでもその辺の話も後でしたいなと思うんだけど、

そのワンステップを、ワンステップ入る、

そこに違和感をどれだけ覚えられるかみたいな問題とかは結構あるよねみたいな話は、

まあ後でまたしたいな。

あとは未来の話で一個記事を置いといたのが、

マイクロソフトが今後の新規のアカウント登録に際して

パスキーの導入とメルカリの現状

パスキーをデフォルトにするよみたいな記事とかがあったりして、

マイクロソフトが率先しちゃってくれるの良いねって話をしてたんですけど、

メルカリはどうなんですか。

いやー、どうかね、何とも言えないですけどね。

でも基本的にはそういう方向性だと思いますね。

メルカリで現状で言えばメルコインってパスワードも使えない状態で

パスキーのみでアクセスしていて、

そこはもうフィッシングにあってない。

一回もフィッシング起きてないんですけど、

他の部はフィッシング起きてたり。

まあそういう状態なんで、

基本的にはパスワードを…

何も言えねえ。

でも基本的にパスワードあるところは狙われるんですよ。

今狙われなかったとしてもそのうち狙われるようになるし、

ビジネス的に成長していったら他の人のターゲットになることもあるから。

大なり小なりやられるっていうのは絶対出てくると思っていて、

特にメルカリがエグい感じになっているのはあると思うけど。

なので基本的にはパスワードを託す方法になと思いますね。

認証方法の重要性

アカウント登録からも削除するし、

既存のユーザーは上手にパスワードを使えなくなっていくか、

パスワードを使っていたら非常に不便な状態に

追い込まれるという言い方はあれですけど、

何回も追加認証要求される。

100文字以上のパスワードが必要かもしれない。

いやだなあ。

こんなパスワードは嫌だ。

機能縛るとかじゃないよ。

こんなパスワードは嫌だ。

出品しかできないとかまだ分かるけど。

それは面白い視点だね。

それは結構アリだなって気がする。

全然パスキーじゃないけど、

メアド認証しなくてもアカウント登録できるけど、

メアド認証するまでは閲覧しかできないようなサースとか

たまにある気がする。

どちらかというとメルカリはそのやり方に近いかな。

特定の機能の利用にパスキーを必要化するみたいなアプローチなので、

そのやり方に比較的近いような気がするな。

特定の機能が使えないみたいな見せ方は

別にしてなくてっていう感じではないかな。

使うために必要。

それでいうとアカウントリカバリの話とかも

それに通ずるところはあるんですよね。

最初アカウント作ったときは特にアカウントの価値は

作ったばかりのものなので何の情報が入っているのか

取られても全くかまわない。

そうなんですか。

新しいアカウントをステイにいっぱい作って

なんかするっていうパターンはありますけど、

一般ユーザーが、正規のユーザーが作ったタイミングでは

パスワード使えてリカバリはいいね、

マジックリンク一本でっていうのはでもいいけど、

クレジットカード登録したり、

いろんな出品したり、

評価が溜まってきたりしてアカウントの価値が溜まってきたら

2ファクター要求するのにパスキー登録するのに

あとはEKYCをしてマイナーバッグカードでリカバリ適当にしたりとか

そんな感じで段階で使う機能に応じて

認証強度とか利用可能なリカバリのメカニズムとか

変えていくっていうのも結構有りなところではある。

まだ価値が高くなる前にっていうのが大事ですよね。

高くなってからだと

一心に引っかかってパスキーいつまで続かれるみたいなパターンも

パスキーを登録した人とアカウントの持ち主が同一であることが

担保しにくくなる。

もっと言うと、アカウントの価値を高める行動をした人と

パスキーを登録した人が同一人物であることが

担保しにくくなるっていう言い方かな。

それで言うと、自分の言ってることをひっくり返すと

やっぱ登録時には最初にはパスキー登録すべきですね。

そしたらアカウント作成した人とその後の人が

そこはパスキーはとりあえず登録してもらうと。

フォールバックとして何を使えるかっていうところで

アカウント価値に応じて弱いフォールバックから

強いフォールバックにどんどん移行していくのがいいかもしれないですね。

それが一つ確かにそうですよ。

じゃあそれで。

それください。

なんかその辺結構サービスとか事業内容に応じて

結構デザインの違いがあるのが。

だから今の時代の新しく何かを始めますっていうときの

最初のテーマの一つだと、もう私は思っていて

新しいサービスを始めますっていうときに

パスアドレスで行きますか最初からどうしますかっていう

問いはぜひ誰もが考える感じになってほしいなとは思う。

みんな生成AIの話してる場合じゃないんじゃないか。

しかも生成AIに頼むとTOTPの実装がおかしなことになる。

あれ本当に面白かったんだよな。もう一回貼っちゃお。

昨日の収録でフラットセキュリティさんの記事を読んだんですけど

レビンに行動化させたみたいなやつで

TOTPによる二要素認証を実装してくださいって言ったときに

IDパスのログインをフォームを押してその後に

TOTPの画面を入力するURLに遷移するときに

そのURLの中にIDパスワードを入れるっていう実装をしてきたって話だった。

それが嫌気味のツボに刺さったっていう。

結構個人的大ヒットになっていて完全に好きなんだよな。

しかもここでは触れられないんだけど

完全に同じ類型の話だよっていうのを

今日全然別のやつで見かけてすげえ面白かったんだよ。

だからそれは後でオフレコンとかでも

すげえ楽しかったね。

正々堰よりパスキー実装さすがに頑張ればできるんだけど

普通にやらせればできるよ。

毎日叩けばいいだけ?

いくらでもサンプルコード転がってるしさ。

やってできないことはないと思うけど。

だから結構そこを話を軌道修正すると

何か新しくサービスを始めるときに最初からパスアドレスで

全アカウントがパスキーを持ってるっていう状態に

できるかどうかが多分要は何て言ったらいいんだろうな。

あんまこういう言い方したくないけど

新卒カードをどこで切るかみたいな話に近くって

割と取り返しのつかない不可逆な意思決定なんですよ。

あとからやるのめっちゃ大変だし

それでもパスキーよくわからんよねっていうので

そういう意思決定をしないっていうのも

否定はしないんだけど、事業ありきであって

パスキーのせいで事業が上手くいかないんだったら

それはちょっと良くないよねって思うから

何とも言えないところではあるんだけど。

明らかに不可逆な意思決定であって

アカウントの価値を高める、サービスの価値を高めるっていう

その前提に立ったときに

最初にすべき投資としてはすごくいい投資だよなって思うんだよね。

みんなどう思ってるんだろうな、すごい気になるな。

ある種もうすでにでかい企業とか、ある種狙われやすい企業は

狙われてるかっていうのが先か、狙われる前っていうのが先かわからんけど

結構パスキーへの移行のモチベーションが高いというか

技術的にも成熟してるからその選択肢がきちんと

自分たちの中から開発的に出るっていう状態だと思うんだけど

僕らが生きてるようなちっちゃい会社とか

これから事業やっていこうみたいな会社が

一番最初にこの議論がきちんとできるかどうかって結構

最近ソフトエンジニアやってないから

いやいやそんなみんな考えてるようになるかもしれないけど

どうなんだろうなっていうのがちょっと思いを発した。

いやなんか漠然と難しいしコスト高いし

ユーザー視点でもコスト高いし

実装視点でもコスト高いしっていうので

避けてませんかっていうのは

世の中に対してすごく言いたい部分ではあって

そうね

別にいいんだよ議論を尽くして

イニシャルではやりませんって意思決定をすること自体を

全然否定しないし

それはそういうこともあるよねって思うから

例えばだけど類似のサービスを

大体似たような時期に始めたA社とB社があって

片方はもうサービスローンチ当初から

バスキーが必須になっていて

使ってる全ユーザーがバスキーを持ってるっていう状態になってます

もう片方はそうではありませんっていう中で

育ってきた時に

そのジャンルのサービスがめっちゃフィッシングとかに狙われるようになった時に

めちゃくちゃ差がつく

そこの機械損失ってめちゃくちゃ大きいはずで

サービスを大きくしていく事業を大きくしていくっていう前提に

例えば立つほど取り返しがつかない不可欠な意思決定って

そうであるからこそ最初に議論を尽くすべきだよね

実際いつ狙われるかいつ攻撃行くか分からないですね

攻撃者がまた当たるか

分かんない

そのやられてる側の中の一視点で言うと

平たく言えば割と波があって

っていうのは言えるかなと思うんだけど

波もあるし

結構最近だと証券系がめっちゃやられてたりするし

ニュースとか見てても分かるぐらいトレンドがあるっていうのは言える部分で

じゃあいつネットスーパーがある一つでめっちゃフィッシングで狙われるような世界っていうのも

もしかしたらあるのかもしれないし

否定できないよね

否定はできない

新サービスとパスキーの議論

そういうところを考えておくと

否定はできない

もちろん登録時にパスキー作成か登録させるっていうのは結構最終的には理想系だと思うんですけど

やっぱり今現時点でパスキーの登録を強制させるのも結構ドロップするんですよね

分かる分かる分かる

なので今から新しいサービス始めるにしても結構そこの最初からパスキー強制しますかしませんかっていうのは

結構どっちが正解って言うと割とない

まだどっちが正解にもなり得ないと思うんですよね

ただ何かしら準備しておかないといつになるか分からないという状態なので

リーズナブルなのはやっぱりパスキー導入だけしておく

ユーザーに対してそんなに意識しなくても使えるような使える登録できるような状態を

登録できるような状態でとりあえずパスキー導入しておく

パスワードは別にその段階では消さなくてもいいよ

なのでユーザーにはそんなに見えないようにしてるけどパスキーを導入してて

自然とパスキーのユーザーが増えていくような状態にしておく

要は今日のレジストレーションとか勝手にパスワードでログインしたら勝手にパスキー作られてるやつとかあるじゃないですか

ああいうのを使って裏でこっそりじゃないですけど

そんなに強く訴求しないけどだんだんパスキーユーザーが増えていくような状態にしておく

いざフィッシングキャンペーンが起こった時には

すでにパスキーが導入されていてある程度のユーザーはパスキーを使ってる状態なので

狙われた機能においてはパスワードを使えないようにしちゃいましょうという選択肢が

現実問題として取れる準備をしておけばおくのがいいんじゃないかなという気はしますね

あとはサインアップの瞬間には要求しないけどアカウントの価値が高くなるタイミングで

合わせて要求するみたいなのも一つの落とし所としてはあるかなと思うし

あとは現実問題難しいよねっていうのはめっちゃ理解しつつ

この辺が多分僕が自分で自分のこと過激派って言ってるのが多分ゆえんだけど

今の世の中で正々堂々今後来ないよねって言ってる人がいないのと同じように

これが当たり前になって必須になっていく世の中がもう来ないことがないよなと私は思っていて

だったら早くやった方が良くないと思うし早く適応していく方に

舵を切った方がいいんじゃないかなって個人的には思っていて

結構過激な思想だと思ったけど

バランスも何もねーよって

サービスの内容とかサービスのユーザーの利き出し

想定される利き出しとかによっては全然それもありじゃないですか

仕事では空気を読むけど個人的にはそういう思想を持って

だからこそマイクロソフトが登録時にパスワード辞めたのはすごいんですよね

あれだけ大きなユーザーベースを持っているところでそれやるんだ

すごいなって気がします

メルカリはどうなんですか

ちょこちょこ詰めるな

いつか我々も

パスキーとセキュリティの課題

安心して安心してガイヤから石を投げられる

楽しそうだな

超楽しい

やっていきたいですね

そんな感じでね

パスキーが当たり前になる世の中になってほしいなと思うし

これから新しいサービスを立ち上げる人は

不可逆な意思決定について

ちょっと時間をとって考えてみてほしいなって思います

やるにしてもやらないにしても

神して意思決定をするべきなんだなって

ていうかね

フィッシングの対応の地獄を一回ね

そこはパスキーに限らずセキュリティの不合理な真実は

ほんとしんどいのよ

誰も何も責められずただやられてるみたいな

ほんとにねあのイタ時刻しんどいんだよな

そのしんどさを発信すべきではって今思ったけど

発信できるような内容でもないなと思って

知らんけどメルカリで不正対策とかやればきっと分かる

なんか過激派なんだよな

他人に突き落として這い上がってもらって

辛かったでしょって食べたってもらうみたいな

そんな感じで

別にねメルカリに限らずいろんなところが

フィッシングとの戦いはしてるはずで

それこそペイペイとかもきっとそうだろうし

最近だと証券系もそうだろうし

クレカとかも当然いっぱいあるだろうから

クレカはないか

クレカってどうなんだフィッシングで

バーチャルカードの情報とか取れたりするのかな

ニュースとかでは見たことないかな

フィッシング以外の不正はよく見たことがある

お金絡むところは特にそういうの多いと思うから

通販系も多いかなきっとね

今勤めてるところでそういうのが起きてるんだったら

是非目を向けてみてほしいなって思うし

むしろやる気に満ち溢れていて

その戦いに身を投じていきたいみたいな気持ちは

そういうところに突っ込んでいくのもいいんじゃないかな

なんかすげえ言い方悪いんだけど

狙われてるところでしかそれは体験できないことだから

でも分かりますね

実際に攻撃受けてる状況にいないと

その攻撃手法って教科書の中の攻撃手法みたいな感じ

そうなんですよ

別に僕ら視点遠い世界の話のように思ってることとかも

やっぱりあってあるはずで

前にもこういう話した気がするんだけど

電子系の基板のサイドチャンネルの話を

大分前に何かの記事で読んだじゃん

これを考えて設計するような暗号系の人たちすごいねって話を確かしたと思うんだけど

それが当たり前の世界で生きてる人たちもいるし

一方でフィッシングとかでめっちゃやられてて

そういう戦いの中でやってるそれが当たり前っていう人たちもいるし

だからみんながみんな見えてる世界は違うんだけど

一つ言いたいのはやられてる狙われてるところじゃないと体験できないことではあるから

あんまこういう言い方したくないけどやりがいのある部分ではあるかもしれない

だって平和ならそれが一番いいじゃん

OJTしに来たよ2週間後に

留学

だって自社サービスでいざそういうことが起きたりしたらしんどいじゃん普通に

認証と認可の専門性

なくて済むならない方が全然嬉しいし

って思うんだよね

って考えたらどうにかしてサービスのローンチの瞬間から全ユーザーパスキー必須にしといたら

その苦しみを味わうことはほぼないわけじゃん

だって過激派しそうに

過激派なのかな過激派って言わなくていい気もするけど

分かるよ

そんなこと思うわけです

そんな感じですね

じゃあちょっとだいぶパスキーの話が続いたけど

どっちからいこうかな

認証認可って結構セキュリティの一つの要素といってしまうにはでかいなって思うんですけど

認証認可の専門家ですみたいな人って結構多いんですか

多いかどっかわからないですけど結構いると思いますね

横の繋がりというかこの会社のあの人とかどの会社のあの人みたいな

認証認可関連で幅を大きくするとあれですけど

その辺にすごい力を入れてる人とかっていうのは結構何もいますね

なんかちょっと良くない感じになったなちょっとカットでお願いします

Pとか入れるとさ誰かバイネームで言ってるのかなって

アテがなかった発言っていう

全然わからない尊敬してます

なんかID界隈みたいなところとはちょっと違うんですかね

俺はまだまだアテがないと言うか

アテがないと言うか

ID界隈みたいなところとはちょっと違うんですかね

同じだと思いますね

同じなのかな

認証とか認可オープンIDをする

パスキー関連の認証の部分とか

あとはアイデンティブルーフィングKYCとか

あの辺の関連は大体同じ人たち

感じがある

なんかその上にもう一段具体のレイヤーが乗ると思っていて

要は認証認可という概念の上で何を実装するかみたいな

領域があると思っていて通じてるかな

僕は通じてる

例えばリバックとかRバックとかを作るときに

Rバックとかを実現するときに

どういうロールとかパーミッションのモデルを

作っていけばいいかみたいなのを

すごく得意にしてる人たちもいると思っていて

そこって一定

なんて言ったらいいんだろうな

互換性があるような領域なんですかね

僕のイメージですけど

多分その上のレイヤーっていうのは

特定のチームとかに割り当てられていて

誰かがスターティングポイントとして入ってくるところだと思う

要はこのチームは認可を担当しているんです

認可サーバーを運営してますみたいな

ところに人が入ってきたらまずそこをやるじゃないですか

結局そこで使ってる概念っていうのが

結局その下の話のいろんな方とつながってる

方とつながってるような状態なんで

先にそこ入ってこの下のレイヤー行って

他のところで手を出し始めるみたいな感じになると思うんですよね

なんで

コククマさんの場合は

コククマさんってある日突然認証認可やり始めました

そうですね突然やり始めましたね

あの時は確か何回入ったんだっけ

なんかすごい相談された記憶があって

認証認可やることになったんですよみたいなことを

初めましてがそんな感じでしたね

なんかなんとなくヤギさんのこと知ってたんですけど

なんかその時に何か

参考になる記事とか本とかないですかみたいなことを

ヤギさんに聞いたら

NISTのSP863の読めばいいよみたいな感じで

言われた記憶があって

そこからですね

なんか不親切な

不親切な

そんなとんだ不親切な奴もいたもんだな

そのあたりから

まあどこかといったら認可の部分かなっていう気がします

応援リコネクトあたりから最初に入った気がします

なるほどね

なんかやっぱ飛び込んでキャッチアップしながら

実際の実装とか現実的な仕様とか言うけど

そういう基礎の知識を活かしながら実装していく過程で

なんていうか

当たり前っちゃ当たり前なのかな

それでやっぱ強くなっていくみたいな感じなんですかねみんな

なんかわかんないですけど

一回仕事で認可の実装まで行かなかったんですけど

実装手前の何だろうな予備調査とか

表現むずいっすか

デザインドックぐらいの抽象との設計までやったことがあって

その時に思ったのが

なんか僕はなんかバックグラウンドが

多分自己紹介っていうかしたかった気がするけど

本当だ

そうですけど

バックエンディンジニアで多分

7年ぐらいかな

7年8年ぐらい働いて

だからアメリカにいた時もバックエンディンジニアとして働いて

ウェブやってたんですけど

フロントエンドもちょっと趣味でかじるぐらいの解像度でやって

直近2年間は

ウェブを隠して座ってセキュリティを

ひひ言いながらやってるみたいな感じ

素晴らしい

ありがとうございます

認証認可のちょっとやんなきゃねみたいな

社内でふわっと

見越していますけど

デザインドックみたいなものを仕上げるってなった時に

わからんなみたいな気持ち

わからんなみたいな気持ちと

ただなんか

僕がわからないって言ってるのは

基礎の部分みたいな部分があって

そこは勉強

一心にやりながら頑張ったんですけど

それと現実のユースケースみたいなのが

実際あると思ってて

うちのサービスとか

ネットスーパーのスタッフさんに

渡さなきゃいけないんで

スタッフさんには

お野菜を詰める人と

それを運ぶ人と

みたいなのがいて

それぞれこういうロールが振られそうで

こういうことができそうみたいな

実際の権限のユースケースがいくつかあったり

そこに特殊な

よくある

RバックとかRバックで全然吸収できなそうな

概念が入ってくるみたいな

あった時にそういう現実の複雑性みたいなのと

基礎をつなげる作業みたいなのが

必要な気がしてて

そこは僕は

エンジンとしてプロダクト作って

エンジンとしては

そっちは割といけるなみたいな

気持ちもありつつ

ただデザイン読で終わっちゃったんで

自分が分かってないのは

これを実際に実装できたのか

実装もそうだし

運用してって

みたいなところもそうだね

結構

めちゃくちゃ素振りが必要なんじゃないか

これをちゃんと

それは変わります

1年2年くらい修行積まないと

認証認可設計して

いい感じにできましたって

言えないものなんだろうなっていう

すごい

スコープのでかさと

難しさと

セキュリティみたいな部分の

絶対に譲ってはいけないラインみたいなのが

あるっていうのが難しさなのかな

私も割と初期に作った

メルカリのMFAとかを

やり直せるなら

めっちゃやり直したいし

そう

いろいろ

趣味で作ったりしてるんですけど

うまくできなかったって言ったら

あれですけど

複雑すぎたな

あまりにも

恐怖に過ぎるというか

こうすべきだよね

っていう感じで

恐怖に管理していて

管理が難しすぎるっていう

のが出てくる

結構ありますね

一方で

手堅い実装にしとかないと

いろんなユースケースが出てきたときに

容易に壊れるんですよね

伝わるか分かんないんだけど

この感覚が伝わるか分かんないんだけど

そういうのが

ユースケースの複雑性

やっぱり

伝わるか分かんないんだけど

この感覚が伝わるか分かんないんだけど

分かるよ

分かる気がする

レジリエンスというか

どこで

どこに弾力性を持たせるか

みたいなところがすごい

職人系な気がするな

すごい感覚的に喋っちゃってるんだけど

聞いてる人にどれだけ伝わるのか

分かんない問題があるんだけど

何だろう

いい例ないかな

思い出せないな

4ヶ月違う

もう半年以上前だった

なんかオレオレOIDCもどきと

なんか正統派のOIDCみたいな

手がたくっていう意味で

これこそだよな

なんか言葉として

どうなのか分かんないんですけど

手がたくとか

いろんなユースケースでサポートできるようにする

とかそういうところで考えると

やっぱり

認証認可の部分は

基準仕様が多いんで

それに従うっていうのが

できる限り従うっていうのが

基本的には

正しい方法だと思いますね

いやマジで

それなんですよ

なるほどね

認証と認可の理解

いろんなユースケースをサポートできるよう

なんかいろんな人が集まって

あれ考えてるって

正直我々の思ってるユースケースとかって

どっかの誰かの

もうすでにやってるユースケースだったりするんで

それに乗っかれるようにするためにも

標準仕様に乗っかっておくっていうのが

やっぱり

いいところ

うん

そうなんですよね

それとも

仕事でリサーチしたとき

そこあんま勉強できてないかも

でなんかその

あんま一般的じゃない

その実装が入れば入るほど

なんかレビューするのとかもやっぱ大変で

なんか忘れるんですよねすぐに

なんかこう

標準仕様が頭に入ってると

それに乗っかってるものは

なんかもうあれでしょって感じなんですけど

それからずれてるもんってなんか

もう

読むのもなんか疲れるし

読んだ後すぐ忘れるし

そうなりますよね

なんか

あれってどうなってたっけ

本当に何回も何回も思い出して忘れるみたいな

そう

なんかすげえしかも

めっちゃドメスティックな知識だから

なんか

なかなかその

覚えておくのも結構しんどいし

うん

大事ではあるんだけど

なかなかね

なるほどね

共通言語でしゃべりにくいみたいな問題とかも

多分あるし

それこそオレオレオープン

相手コネクトじゃないけど

うん

いやー確かに何とは言えないが

思い当たる節はあるな

うん

あとは

なんかちょっと全然話変わるんですけど

なんかさっきのその

なんか

スタッフさんがいてみたいな話で思い出したんだけど

うん

なんか結構アールバックとリバックの間が

隔絶があるなって最近思ってて

うん

ちょっとこれも伝わるか分かんねえな

分かる分かる分かる

要はアールバックは結構

イメージしやすいし

自分で実装上だったらできるけど

リバックになると

っていうのもあるし

そうそうそう

かつリバックまでいらねえんだよなっていう

ユースケースが結構多くて

なるほど

なんか割と個人的に綺麗だなって思ってる

そのロールパーミッションモデルが

Google Cloudのやつで

なんかあれは結構綺麗だなと思うんだけど

あれってでも頭にプロジェクトがついてるから

なんか割と綺麗に成立するよなと思うんだよね

で一方でその

例えばネットスーパーとかは

そのなんて言ってるんだろうな

エリアとか店舗の概念があって

とかがあるじゃん

そうするとその

なんて言ってるんだろうな

プロジェクトの下にロールがぶら下がるんじゃなくて

人の下

ロールの下に

なんていうか

Google Cloudとかっていう

プロジェクト的な概念がぶら下がってくるじゃん

あー

であれを評価すると

まあでも設計次第な気がするんだよな

設計次第だけど

でもあれを表現しようと思った時に

素直に表現しようとすると

Rバックだと結構苦しいよなって思ってて

あといってリバックまで行くと

なんか重すぎるよなって思ってて

うんうんうん

なんかそこは

いやーなんか

具体的にはしゃべる

まあしゃべってもまあいい

まあだから平たく言うとなんか

まあね難しいな

でも結構こう

わからない

僕がたぶん素振りをしたことがないとか

知識がないがゆえにそう思ってる説も

多分にある上で

の発言なんだけど

めっちゃ保険かけちゃったけど

うん

なんで僕がそんなにめちゃくちゃ

なんか超えられない壁がある

とまではあんま思ってなくて

うんうん

さっき仕事で

デザイン的なものを仕上げて

いろいろ考えてた時は

結構その実装次第で

うーん

いや分かるよ

表現難しいんだけどさっきのレジリエンスみたいな話に

個人的にはつながる気がして

分かる分かりつつ

うんいいよ

ベースRバックで吸収できるとこまで吸収してみて

ただどっかのためにリバックになる可能性も

なんか事業上はありえそうみたいな

うーん

リバックになるというか

リバックにしなきゃいけないぐらい

現実のリソースの関係性が

その権限に認可に絡んでくるとか

うんうん

そういうの可能性が否定できない以上は

そっちにも舵取りをできるように

うん

じゃあなんか実際のコードベースで考えた時に

どういう作りにしとくと

一番痛みが少なそうかみたいな

うん

観点で結構考えてて

なんかそこで工夫の余地はあるんじゃ

分かろうかという

でただ素振りをしてないから

絵に描いた持ち施設も全然あって

ここまでしかいらないって感じなんだけど

なるほどねー

うん

それ自体は結構分かるし

まあそうなんだろうなと思うんだけど

なんかこうそこで使えるこう

まあそういうケースだったら

このモデルがいいよねっていう

なんかあるバックリバック的なものが

一個あればなんか救われる人が

多いんじゃないかなっていう話

それはなんか知りたいけど

なんかあの当時なんだっけな

オーサレイゼーションアカデミーっていう

うん

やつを全部読んだんだけど

うんうん

なんか銀の弾がなさそう

笑

結構丁寧に描いた

まああれで抜けてるものがあるんだったら

多分それは僕のキャッチアップ不足なんで

なんかぜひ知りたいって感じだけど

まああれよんな感じは

まあまあそうだよねって感じ

うん

リバック

ああ貼っとくか

うんオーサレイゼーション

ああ貼っとくよ

なんかのねなんかのその

それこそ認可周りのDSLを描いたら

うん

それが作った時期で

誰かにオススメ

ああ嘘かそうだね

うん

そうだね

結構

うーん

なんか分かんない

結構思ったのはやっぱ仕様

仕様にめちゃくちゃ向き合うのが

大事なんじゃないかと思ったんだよな

まあ基礎的な知識をちゃんと抑えつつでは

なんだけど

うん

まあ

そう思ってる

その仕様

標準仕様に従うのは大切だと思うんですけど

やっぱ標準仕様に書いてないもんね

いっぱいあるんで

結局

今現実問題自分が向き合ってる問題に

どう対処するかっていうのは

なんか

標準仕様を武器に

なんか自分で考えて戦うしかない

っていう状態になるんですよね

うん

アールバックとリバックの違い

結局その上で何作りますかっていう部分は

まあ

その

一個線引きがあるよなって個人的には思っていて

うん

そうだね

そういう意味でこのオーサイゼーションアカデミーは

すごい良かったんだよな

良かったよねこれね

うんモデルがあってそのモデルを実際

コードベースでどうするのとか

いやー分かると思ったな

何でしょうね

見てる人によって検索結果のフィルターを

しなきゃいけないみたいな

自分のリソースが

自分のリソースがリバックの世界だよね

作ったリソースは検索結果に出てきてほしい

みたいな時に

なんかどのレイヤーで

SQLに投げるSQLを変えるのか

違う違うSQLのウェアで処理するのか

その手前のところで

全件取ってきてフィルターするのかみたいな

どのレイヤーでやるのみたいな話とか

レイヤー複数に分かれると

じゃあどこへロールチェックを漏れなくすんのみたいな

そういう話が書いてあって

うんうん

なんかバックエンドエンジニアの方としては

あー分かるみたいな感じで

もう腕の見せ床だよなみたいな気持ち

うんうん

面白いね

まあでも武器はね

ちゃんとあった方がいいっていうのはめっちゃ多いので

武器は間違いなく必要だなって気がする

なんか定石を知ってるかどうかで

結構なんか

そうだね

知らなかったら多分車輪の再発明みたいなのが

容易に起きる気はする

そうそうそうそう

ことなんか

セキュリティレベルという観点においては

その声はかなりリスクが高い気もしてる

うんうん

なんかそんな感じで

ちょっと開発の話が続いたんだけど

星の数

エピソードをシェアする

メッセージを送信

Sota Sugiura

サマリー

目次

星の数

コメント

こちらもおすすめ