アカウント名:
パスワード:
よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。
パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。私の場合、セブンペイだったら seven-pay-qihu1r4ratf4jahg@example.com のようにします。qihu1r4ratf4jahg の部分はサービス毎に別のランダムな英数字にします。example.com は独自ドメインで、有効なメールアドレス（@の左部）はコマンド1行で増やせるようにしています。
この方法は、同時に迷惑メール対策（どこから漏洩したか分かるし、迷惑メールが来たメールアドレスのみ切り捨てるのも容易）や、フィッシング詐欺メール対策にもなります。
パスワードリマインダーもID＝メールアドレスが分からないと使えないことが多いので、リマインダーの悪用も防げます。今回のセブンペイみたいに、パスワードリマインダーも、認証も何もかも酷いサービスであっても、ID＝メールアドレスがランダムであるならば悪用はされませんでした。
皆さん、ID＝メールアドレスはランダムにして、使いまわさないようにしましょう。
Sign in with Apple最大の特徴は、簡単便利な生体認証を利用した二段階認証とアカウントを作成するときのメールアドレスの取り扱い方法です。
まず、ログインするときは指紋認証（Touch ID）または顔認証（Face ID）を利用し、パスワード入力は不要。これはとても便利です。スマホを持って画面を見ていればいいので、二段階の煩わしさはまったく感じません（Googleのサードパーティアプリも指紋認証が使えるところもあるんですが、まだそこまで普及してません）。
そして、アカウントを作成する時、通常はメールアドレスを入力するところですが、実際使っているアドレスはあまり公開したくないですよね。そういった方のためにAppleはランダムな文字を組み合わせて、臨時のメールアドレスを作ってくれます。なので、サードパーティ側に実際のアドレスを知られずに済みます。広告会社など、メールアドレスからユーザの情報を得ることも多いので、ランダムなアドレスなら安心です。ちなみに、アプリなどからメールが来た場合は、Appleが元のアドレスに転送してくれます。https://www.gizmodo.jp/2019/06/details-of-sign-in-with-apple.html [gizmodo.jp]
＞パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。その方法の弱点は、パスワードを忘れちゃうような人だとIDも分からなくなって、パスワードリセットもできないから本人が二度とログイン不可能になっちゃうことですね。＃誰もログインできないと言う意味では鉄壁の防御と言っていいのかな？
登録E-mailアドレスと、ログインIDを独立したものにして、パスワード（とID）のリセットはE-mailアドレスを中心に実行するあたりが落とし所かな。これさえもIDを覚えるのが面倒という人の前にはなんの意味もない。
そういう意味ではケータイ使った二段階認証って、ほんと良く考えられたシステムだと思う。
確かにその方が望ましいけれども、世の中のすべての人が気軽にメールアドレス増やせる環境なわけじゃない用意できる人なら「糞みたいなパスワードリマインダー等」の心配はまず不要だろうし、Google等のメールアカウントをサービス毎に用意するのはどうかと思う
Gmailだとしたら、hoge@gmail.com のアドレスあったら、hoge+abcdefg@gmail.com や hoge+ifiaufuf@gmail.com のようなアドレスも自動で同じメールボックスに受信できますよ。フィルター機能でラベル分けすることもできます。なので、サービス毎にメールアドレスを分けるのも簡単にできます。
ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。
+ は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。Gmailのエイリアスが弾かれる不具合というのは、RFCを守らないでいい加減なバリデーションをやっていると、困ったことになるという良い例ですね。
あと、半可通が "." (ドット) が2つ以上連続するメールアドレスはRFC違反だという出鱈目を広めてしまった（何故か信じている技術者が多い）せいで、わざわざドットの連続を正規表現で弾く糞サイトが最近増えてきているようです。どっかのライブラリがそうしているのかもしれませんが。
正しくは、local-part を quoted-string (") で囲えば、" と \ を除く すべての記号 （印字可能 ASCII 記号）が利用できます。 さらに、quoted-string の中では quoted-pair が利用できると書かれているので、" と \ でさえも、直前に \ を配置すれば利用できます。
つまり
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
はRFC準拠の正しいメールアドレスです。これが弾かれるシステムは糞ですので、試してみると良いと思います。糞システムを検出するリトマス試験紙になります。
[参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意をhttps://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
> [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を> https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
この記事のコメントによるとSMTPに限定しているようだが、それなら参照するのはRFC 5321のほうがいいと思うの(間違っているまとめに言えという話かもしれんが)。FWSとかコメントとか考えなくてよくなるし。
で、RFC 5321には> While the above definition for Local-part is relatively permissive,> for maximum interoperability, a host that expects to receive mail> SHOULD avoid defining
むしろE-mailアドレスについては、アドレスの方が糞仕様，又は仕様バグだよねとしか。仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。
あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。JavaScriptが糞言語であるのと同じような物．
態々試さないけど、メールアドレスの正確な仕様に沿っているシステムってどんだけあるんだろ。
こんなんウチのシステムに受け入れていいのかって逆に思う。まともにメールをやりとりできる気がしない。
# フレームワークのバリデーションをそのまま使ってる。それが正確かどうかなんてしらん。
もはや昔話だけど、日本にはNTTドコモっていう、「仕様で認められないアドレスが選べて、スパムが来なくて便利」というのをウリにしていた恐ろしい大企業があったんだぞ。
「正しいE-mailアドレス」に準拠することの無意味さを教えられました。＃IE6の残した教訓：無理が通れば道理が引っ込む.
逆に、皆がもうRFC5322の”でくくればなんでもありみたいな規定をやめるように考えてくれたらいいのに。
RFCは完璧で絶対遵守ってものじゃないよ。他人を貶す道具にしたい人には便利なものかもしれないけどね。
でも今更変えようとなると、折角だからUTF-8に対応させようとか、アプリケーション固有の拡張ができるようにメタ構造を作ろうとか、余計なこと言い出すやつが現れるに決まっている。そしてセキュリティの話になって、そもそも論が始まる。
+ をはじくのは糞システムだというのはわかるけど" をはじかないシステムに出会ったことがない
「弾く糞サイト」というのは、どういう状況なのだろう？たとえばWebメールで宛先に入力すると拒否されるというのならそれは確かに問題だが、メールアカウントを新規作成するときにRFCよりも厳しい基準にすることはサービス提供者の自由だし、問題はないと思うが。
問題ないから糞扱いなんだろ。直しようがないんだから。
エイリアス使って無限にアカウント作られるのを防止する目的もありそう。
gmailは「.」を無視するので、gmail特化でユーザ名を正規化してるのでない場合はどこに「.」を入れるかによって2^(文字数-1)個のアドレス使い分けができるかもです。
その仕様、あまりに有名になってしまったので、そろそろhoge+abcdefg@gmail.comからhoge@gmail.comを復元して迷惑メール送ってくる業者とかログイン試す犯罪者とかいろいろ出てきておかしくなさそう。（ログインはhoge+ifiaufuf@gmail.comとか使ってると弾かれるだろうがその機能を知る前にうっかり生のhoge@gmail.comでアカウント作っちゃったケースがあるかもしれない）
appleの仕様ならそういうことは起きないだろうと予測できる。
お金やらからまない一般サイトでは、パスワードをサイトごとに別のランダムにして、それをパスワード管理ソフトや、ブラウザのパスワード保存機能で覚えさせておくのが最適では？
お金が絡む7IDにパスワード無しで悪用できる穴が空いてたから記事が立った
その上でパスワードもqihu1r4ratf4jahgのようにしてサイトごとに変えておけば、ひとつ漏れても大丈夫だし、メールアドレスと対になっているから忘れないのでポストイットでディスプレイに貼っておかなくても良いし、セキュリティ的にかなり強固になるね
そもそもメアドをIDにするなよと。そこからシステムが間違ってる。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
ID＝メールアドレスをランダムにすべき (スコア:0)
よくパスワードをランダム主張するのが良いというセキュリティの専門家が居ますが、
現実としては糞みたいなパスワードリマインダー等が蔓延っているので、パスワードだけ安全にしてもアカウントを守れるとは限りません。
パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。
私の場合、セブンペイだったら seven-pay-qihu1r4ratf4jahg@example.com のようにします。
qihu1r4ratf4jahg の部分はサービス毎に別のランダムな英数字にします。
example.com は独自ドメインで、有効なメールアドレス（@の左部）はコマンド1行で増やせるようにしています。
この方法は、同時に迷惑メール対策（どこから漏洩したか分かるし、迷惑メールが来たメールアドレスのみ切り捨てるのも容易）や、フィッシング詐欺メール対策にもなります。
パスワードリマインダーもID＝メールアドレスが分からないと使えないことが多いので、リマインダーの悪用も防げます。
今回のセブンペイみたいに、パスワードリマインダーも、認証も何もかも酷いサービスであっても、ID＝メールアドレスがランダムであるならば悪用はされませんでした。
皆さん、ID＝メールアドレスはランダムにして、使いまわさないようにしましょう。
Re:ID＝メールアドレスをランダムにすべき (スコア:1)
Sign in with Apple最大の特徴は、簡単便利な生体認証を利用した二段階認証とアカウントを作成するときのメールアドレスの取り扱い方法です。
まず、ログインするときは指紋認証（Touch ID）または顔認証（Face ID）を利用し、パスワード入力は不要。これはとても便利です。スマホを持って画面を見ていればいいので、二段階の煩わしさはまったく感じません（Googleのサードパーティアプリも指紋認証が使えるところもあるんですが、まだそこまで普及してません）。
そして、アカウントを作成する時、通常はメールアドレスを入力するところですが、実際使っているアドレスはあまり公開したくないですよね。そういった方のためにAppleはランダムな文字を組み合わせて、臨時のメールアドレスを作ってくれます。なので、サードパーティ側に実際のアドレスを知られずに済みます。広告会社など、メールアドレスからユーザの情報を得ることも多いので、ランダムなアドレスなら安心です。ちなみに、アプリなどからメールが来た場合は、Appleが元のアドレスに転送してくれます。
https://www.gizmodo.jp/2019/06/details-of-sign-in-with-apple.html [gizmodo.jp]
Re: (スコア:0)
＞パスワードだけでなく、ID＝メールアドレスもランダムにして、サービス毎に違うものにすべきです。
その方法の弱点は、パスワードを忘れちゃうような人だとIDも分からなくなって、
パスワードリセットもできないから本人が二度とログイン不可能になっちゃうことですね。
＃誰もログインできないと言う意味では鉄壁の防御と言っていいのかな？
登録E-mailアドレスと、ログインIDを独立したものにして、パスワード（とID）のリセットは
E-mailアドレスを中心に実行するあたりが落とし所かな。
これさえもIDを覚えるのが面倒という人の前にはなんの意味もない。
そういう意味ではケータイ使った二段階認証って、ほんと良く考えられたシステムだと思う。
Re: (スコア:0)
確かにその方が望ましいけれども、世の中のすべての人が気軽にメールアドレス増やせる環境なわけじゃない
用意できる人なら「糞みたいなパスワードリマインダー等」の心配はまず不要だろうし、Google等のメールアカウントをサービス毎に用意するのはどうかと思う
Gmailは+nameで対応済み (スコア:2, 参考になる)
Gmailだとしたら、
hoge@gmail.com のアドレスあったら、hoge+abcdefg@gmail.com や hoge+ifiaufuf@gmail.com のようなアドレスも自動で同じメールボックスに受信できますよ。
フィルター機能でラベル分けすることもできます。
なので、サービス毎にメールアドレスを分けるのも簡単にできます。
Re:Gmailは+nameで対応済み (スコア:1)
ただ + が入っていると不正なメールアドレスとする困ったサイトが一定存在するのが難点。
皆がRFC5322を守れば良いのに (スコア:1)
+ は本来普通に使うができるはずなのに、弾く糞サイトがあるのは困ったものですね。
Gmailのエイリアスが弾かれる不具合というのは、RFCを守らないでいい加減なバリデーションをやっていると、困ったことになるという良い例ですね。
あと、半可通が "." (ドット) が2つ以上連続するメールアドレスはRFC違反だという出鱈目を広めてしまった（何故か信じている技術者が多い）せいで、わざわざドットの連続を正規表現で弾く糞サイトが最近増えてきているようです。どっかのライブラリがそうしているのかもしれませんが。
正しくは、local-part を quoted-string (") で囲えば、" と \ を除く すべての記号 （印字可能 ASCII 記号）が利用できます。 さらに、quoted-string の中では quoted-pair が利用できると書かれているので、" と \ でさえも、直前に \ を配置すれば利用できます。
つまり
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
はRFC準拠の正しいメールアドレスです。これが弾かれるシステムは糞ですので、試してみると良いと思います。糞システムを検出するリトマス試験紙になります。
[参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
Re: (スコア:0)
> [参考] 「メールアドレスのルール」系まとめがそろって間違ってるのでご注意を
> https://orgachem.hatenablog.com/entry/2013/11/26/015343 [hatenablog.com]
この記事のコメントによるとSMTPに限定しているようだが、それなら参照するのはRFC 5321のほうがいいと思うの(間違っているまとめに言えという話かもしれんが)。FWSとかコメントとか考えなくてよくなるし。
で、RFC 5321には
> While the above definition for Local-part is relatively permissive,
> for maximum interoperability, a host that expects to receive mail
> SHOULD avoid defining
Re: (スコア:0)
むしろE-mailアドレスについては、アドレスの方が糞仕様，又は仕様バグだよねとしか。
仕様を記述するのもバリデータを実装するのも苦労するような仕様にするなよと。
あの時代にバリデーションの実装とか考えずに、即興で作ったものならまあそんなもんだろけど。
JavaScriptが糞言語であるのと同じような物．
Re: (スコア:0)
態々試さないけど、メールアドレスの正確な仕様に沿っているシステムってどんだけあるんだろ。
"\\.....!#$%&'*+-/=?^_`{|}~.....\""@example.com
こんなんウチのシステムに受け入れていいのかって逆に思う。まともにメールをやりとりできる気がしない。
# フレームワークのバリデーションをそのまま使ってる。それが正確かどうかなんてしらん。
Re: (スコア:0)
もはや昔話だけど、日本にはNTTドコモっていう、
「仕様で認められないアドレスが選べて、スパムが来なくて便利」
というのをウリにしていた恐ろしい大企業があったんだぞ。
「正しいE-mailアドレス」に準拠することの無意味さを教えられました。
＃IE6の残した教訓：無理が通れば道理が引っ込む.
Re: (スコア:0)
逆に、皆がもうRFC5322の”でくくればなんでもありみたいな規定をやめるように考えてくれたらいいのに。
RFCは完璧で絶対遵守ってものじゃないよ。他人を貶す道具にしたい人には便利なものかもしれないけどね。
Re: (スコア:0)
でも今更変えようとなると、折角だからUTF-8に対応させようとか、
アプリケーション固有の拡張ができるようにメタ構造を作ろうとか、
余計なこと言い出すやつが現れるに決まっている。
そしてセキュリティの話になって、そもそも論が始まる。
Re: (スコア:0)
+ をはじくのは糞システムだというのはわかるけど
" をはじかないシステムに出会ったことがない
Re: (スコア:0)
「弾く糞サイト」というのは、どういう状況なのだろう？たとえばWebメールで宛先に入力すると拒否されるというのならそれは確かに問題だが、メールアカウントを新規作成するときにRFCよりも厳しい基準にすることはサービス提供者の自由だし、問題はないと思うが。
Re: (スコア:0)
問題ないから糞扱いなんだろ。
直しようがないんだから。
Re: (スコア:0)
エイリアス使って無限にアカウント作られるのを防止する目的もありそう。
Re: (スコア:0)
gmailは「.」を無視するので、
gmail特化でユーザ名を正規化してるのでない場合は
どこに「.」を入れるかによって2^(文字数-1)個のアドレス使い分けができるかもです。
Re: (スコア:0)
その仕様、あまりに有名になってしまったので、
そろそろhoge+abcdefg@gmail.comからhoge@gmail.comを復元して迷惑メール送ってくる業者とかログイン試す犯罪者とかいろいろ出てきておかしくなさそう。
（ログインはhoge+ifiaufuf@gmail.comとか使ってると弾かれるだろうがその機能を知る前にうっかり生のhoge@gmail.comでアカウント作っちゃったケースがあるかもしれない）
appleの仕様ならそういうことは起きないだろうと予測できる。
Re: (スコア:0)
お金やらからまない一般サイトでは、パスワードをサイトごとに別のランダムにして、
それをパスワード管理ソフトや、ブラウザのパスワード保存機能で覚えさせておくのが最適では？
Re: (スコア:0)
お金が絡む7IDにパスワード無しで悪用できる穴が空いてたから記事が立った
Re: (スコア:0)
その上でパスワードもqihu1r4ratf4jahgのようにしてサイトごとに変えておけば、ひとつ漏れても大丈夫だし、メールアドレスと対になっているから忘れないのでポストイットでディスプレイに貼っておかなくても良いし、セキュリティ的にかなり強固になるね
Re: (スコア:0)
そもそもメアドをIDにするなよと。
そこからシステムが間違ってる。