  |
はてなキーワード: メールアドレスとは
ほい
[B! security] Google, Slackなどの最先端のサービスのログインフォームで、メールアドレス欄とパスワード欄をわけるようになったのはなぜですか？ - Quora
後のトラブル回避のために2人（あるいはそれ以上）の間で事前合意が存在したことを保証するサイトの概要
PCやスマートフォンなどでサイトにアクセスし、行為者となる予定の人物が新規合意書作成ページにアクセスすることで新規プロジェクトが生成される。
日時やIPアドレス等をハッシュ化しユニークな、部外者に推測されないURLを生成する、この作成ページに個人情報を含めてはならない。
この作成ページにおいて、行為の開始予定時刻や終了予定時刻見積もり、予定されるセックス内容やその他特約をフォームに入力していくことで合意書を作成する。
作成完了後に入力内容は編集不可能となり確認ページとなる。そのURLを参加予定者間でシェアする。このページは24時間経過後、あるいは作成者によって削除が可能。
合意書を作成した当人および他の参加予定者は、同意書に納得したならその確認ページの最下部に用意された合意書送付先に
各々のメールアドレス等を入力する、LINE等のSNSにも対応させることが望ましい。
入力した連絡先に契約内容と、内容に同意するならクリックするユニークなリンクを作成する、絶対に推測可能なものにしてはならない。
アクセス先には本当に同意するかという質問と、Captchaを用意、さらにその後で同意するかを再度問う。
この作業が全員分完了した時に当事者の合意が取れたものとし、その旨を全員に送付し同時に同意があったことを保証するページを入力内容とともに作成。
このページを人為的に削除する方法は用意されず、民事時効となる20年経過後に自動消滅する。
ただしこの合意書にも個人情報を含めてはならない、入力した当事者らの連絡先などをハッシュ化することで再現可能なUUIDを文章内に含める。
後のトラブル回避のために2人（あるいはそれ以上）の間で事前合意が存在したことを保証するサイトの概要
PCやスマートフォンなどでサイトにアクセスし、行為者となる予定の人物が新規合意書作成ページにアクセスすることで新規プロジェクトが生成される。
日時やIPアドレス等をハッシュ化しユニークな、部外者に推測されないURLを生成する、この作成ページに個人情報を含めてはならない。
この作成ページにおいて、行為の開始予定時刻や終了予定時刻見積もり、予定されるセックス内容やその他特約をフォームに入力していくことで合意書を作成する。
作成完了後に入力内容は編集不可能となり確認ページとなる。そのURLを参加予定者間でシェアする。このページは24時間経過後、あるいは作成者によって削除が可能。
合意書を作成した当人および他の参加予定者は、同意書に納得したならその確認ページの最下部に用意された合意書送付先に
各々のメールアドレス等を入力する、LINE等のSNSにも対応させることが望ましい。
入力した連絡先に契約内容と、内容に同意するならクリックするユニークなリンクを作成する、絶対に推測可能なものにしてはならない。
アクセス先には本当に同意するかという質問と、Captchaを用意、さらにその後で同意するかを再度問う。
この作業が全員分完了した時に当事者の合意が取れたものとし、その旨を全員に送付し同時に同意があったことを保証するページを入力内容とともに作成。
このページを人為的に削除する方法は用意されず、民事時効となる20年経過後に自動消滅する。
ただしこの合意書にも個人情報を含めてはならない、入力した当事者らの連絡先などをハッシュ化することで再現可能なUUIDを文章内に含める。
お使いのメールアドレスと生年月日を入力していただければ強固なパスワードを自動で生成いたします。
ご入力いただいたメールアドレスと生年月日、当サイトで生成されたパスワードを用いてxxx側のご登録手続きを行なってください。
ここ連日騒がれている7pay。
パスワードリセットリンク送付先のメールアドレスに対して設計上の問題で脆弱性が発覚して大変な事態に発展しています。
昨日の会見では社長のITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています。
また、会見内で「セキュリティー審査を実施した」と明言がされました。
https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html
セキュリティー審査を実施していたにも関わらず、何故今回の問題が見逃されたのか。
非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います。
その名の通り、サービスローンチ前に実施する、脆弱性や問題がないかの審査の事・・・だと解釈しました。
一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます。
「実施した」とはいっても、どういった内容を実施したかはわかりません。
ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチな脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います。
通常、脆弱性診断というと、以下のような項目があげられると思います。
抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います。
詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています。
LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティ、スプラウトなど。
ただ、今回の脆弱性診断が外部ベンダで実施されたのか、内部で実施されたのかはわかりません。
以下、推測をつらつら書いていきます。
脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります。
Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます。
また、数量計算もベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。
お願いすれば見積もり時にステージング環境で動いているWebサービスをクロールして、各ページの評価を付けてくれるベンダもあります。
規模と見積もり内容にもよりますが、100～200万といったところでしょうか。
スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万～100万程度でしょうか。
プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います。
これ以外にWebSocketを使っていたり、別のサービスと連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります。
Webサービス200万、スマホアプリ(iOS、Android)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。
脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。
そしてこれをそのまま発注するかと言われると、多分しないでしょう。
セキュリティはお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。
経営層は中々首を縦には振らないでしょう。
会見でも明らかになったことですが、社長のITリテラシはあまり高そうにありません。
こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。
また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。
いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。
削れるものをあげていってみましょう。
例えば、iOS用スマホアプリは実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からのアクセスは基本不可であるためです。確か。
そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセス用インターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータはほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います。
・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。
プラットフォームも、ベンダによりますが実施しなくとも良いとも思います。
ベンダの説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います。
Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います。
サーバのコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。
そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。
ワイドショーでは「不正は海外IPからで、国外からのアクセスを許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります。
実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います。
Webサービスですが、ログイン・ログアウト処理は必須でしょう。また、新規登録、情報変更、退会処理も重要です。
パスワードリセットはどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。
ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。
ただ、NRIにはNRIセキュアというセキュリティに特化した子会社が存在しています。
もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います。
ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。
NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります。
別のベンダに発注したことで、抜け落ちた可能性はゼロではないかもしれません。
また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料をセブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断はセブンに委ねられます。
考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・。
ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます。
使ったことはありませんが、SecurityBlanket 365というサービスは自動での定期診断が可能なようです。
ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダに逐次依頼する脆弱性診断よりかは安く済むはずです。
ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。
ツールの手が届く範囲での、XSSやPoC、ヘッダの有無など、ごく一般的な脆弱性診断になると考えられます。
でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。
脆弱性診断ツールはOSSのものもあればベンダが販売していたり、SaaSで提供しているものもあります。
OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります。
ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。
有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います。
SASTになると、RIPS TECH、Contrast Securityなどでしょうか。
上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。
こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。
ただし、社内のエンジニアに任せる事になるため、片手間になってしまう可能性があります。
また、ツールの使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います。
・・・とは言ってもセブンにはCSIRT部隊がちゃんとあるんですよね。
https://www.nca.gr.jp/member/7icsirt.html
『7&i CSIRT は、7&i グループの CSIRT として設置され、グループ企業に対してサービスを提供しています。』と記載があります。
また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています。
グループ企業の情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査・分析とリスク情報の共有、ならびにインシデント対応活動を行なっています。』
という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。
組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会、情報管理委員会のどこかに所属しているんじゃないかと思われます。
日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバーは専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。
なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います。
会見内で言われた二段階認証も検討事項に上がらなかったのかなあ・・・と。
で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。
https://www.7pay.co.jp/news/news_20190705_01.pdf
これを見ると内部のCSIRTが機能していなかったか、力不足と判断されたかどちらかになるのかな・・・と。
実際はどうだかわかりませんけど・・・。
これも有り得る話かなあ・・・と。
開発やベンダやCSIRT部隊が情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧な表現で伝わっていなかったとか・・・。
ベンダが実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。
7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応に時間を取られることになります。
そういった事を許さない空気が出来上がっていると、まあ中々上には上がってきづらいです。
これも十分にありえる話ですかね。ないといいんですけど。
どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。
そこで思ったのですが、情報セキュリティ基本方針と個人情報保護方針を元にしたチェックリストのようなものがセブン内にあって、それを埋めた・・・みたいなことを「セキュリティー審査」と言っていたりするのかなと思ってしまったんですね。
でもこれはセブンペイの社長が個人情報保護管理責任者ということで、ISMSやPMS等で慣れ親しんだ単語である『審査』を使っただけかもしれません。
そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業が・・・。
大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・。
というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。
そういえばomni7で以下のお知らせが上がっていましたね。
https://www.omni7.jp/general/static/info190705
『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。
もしくはわかりやすい対策を提示しろと言われたのかもしれません。それなら仕方ないんですけど。
以上。
一部typoとか指摘事項を修正しました(役不足→力不足 etc)。
ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。
ちゃんと読んでいただけましたか？全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・。
一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性や問題がないかの審査の事」、つまり「脆弱性診断」を指していると仮定して本エントリを書いています。
そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。
監査は貴方の記載する通り「ある事象・対象に関し、遵守すべき法令や社内規程などの規準に照らして、業務や成果物がそれらに則っているかどうかの証拠を収集し、その証拠に基づいて、監査対象の有効性を利害関係者に合理的に保証すること」です。
貴方の言う「監査」に近いことは「セキュリティー審査自体が、情報セキュリティ基本方針と個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48
7iDはもともと2015年11月に開始したセブン＆アイグループの総合通販サイト「オムニ7」用の「オムニ7会員」が名称変更したものだ。
結局はこれ。
悪意の攻撃が行われないだろうと言う前提のもとでは、とにかく、お客様の利便性を優先し、
ＭＮＰによって携帯のキャリアを変えた挙句、登録時のメールアドレスが使えなくなってしまったバカなお客様でも簡単に
サポートセンターの力を借りることなくパスワード変更が出来たほうがシステム全体としては都合が良かったのだ。
二段階認証にして金を掛けても、せいぜい割引クーポンがセキュアに発行できるだけでは、意味がない。
オムニ7のサービス形態全体を見て、コスパの良い、ある意味手を抜いたセキュリティにしていたのは、それほど間違った判断ではなかった。
メールアドレスと誕生日が分かれば、いくらでもパスワード再発行で乗っ取られてしまう！
こんな状況の時に、とっさに自分の登録してある誕生日を変える という手段が取れた人は
ちょっと賢いなっておもいました。まる。
あ、そうか。「パスワード忘れた済まんゴ」の画面から入って手当たり次第に知ってるメールアドレスとと自分のメールアドレス入れてリマインドか。
これなら慣れてる奴は秒で気付くし第三社でも余裕で実行可能だな。
・パスワード長に制限がある（覚えやすく強力なパスワードを作りにくい）
・パスワード設定時の再入力でコピペ禁止（パスワード生成ソフトのランダム文字列が使いにくい。というかそもそも同じものを2回入力させる意味がない。間違えたら再発行や再設定で対応すればよい）
・秘密の質問がある（利用者が忘れたら再発行・再設定で対応すればよい）
・パスワード再設定時にIDに設定したメールアドレス以外のメールアドレスを送付先として利用できる（メールアドレスと生年月日がわかれば他人がパスワードを再設定できる。つまり他のサービスで漏洩した情報だけで認証を突破できる。）
・7idログイン用のパスワードと7payのチャージに必要な認証パスワードに同一のものを利用できる（フールプルーフのない不完全な多段階認証）
・パスワード変更してもログインしているアプリから自動ログアウトされない（他人が不正ログインに成功したらパスワード変更しても意味がない）
他になんかある？
そうなんですよ。ほとんどLINEを使うためだけにスマホやタブレットを持っている高齢者はそもそもgmailの存在をよく分かっていないし、使いもしないです。
androidだとgmailのアカウントがないと動かないので、うちの母のタブレット設定するときに適当に作ったけど、「このタブレットはLINEの他にメールアプリも入っていて、そのアドレスでパソコンとかとメールのやり取りができる」とか言うとかえって混乱しそうなので教えてないです。
ただ、うちの両親はいまだにプロバイダのくれたメールアドレスを夫婦兼用で使っており、かつそのアドレスとメールソフトでメールを送受信する設定方法を分かっていないため、webメールでそのアドレスに届いたメールをチェックしているので、gmailに移行させた方が良いのかも知れない。パスワードとか送受信用のサーバー情報とかが分かれば私がメールソフトの設定するんだけど。
元増田です。
一例です。
長年So-netを使っているので多くのサービス登録にここのメールアドレスが登録されています。
また、ここのメールアドレスでしか連絡のつかない人もいるわけですね。
にも関わらず、
13.メールアドレスを変更しなければならないのか
現時点では変更不要です。(※)
(※)サービス提供内容につきましては、外部環境の変化等に伴い、変更される場合がございます。変更される場合には、NTTぷらら又は弊社から事前に変更内容をご案内させていただきます。
こんな変更時期がどうとでもとれる書かれ方をしては安心できません。
接続サービス全体が譲渡されるならともかく、一部の利用者だけ譲渡される、つまり(ぷららではなく)So-net自体にメールアドレスサービスが残るなら、
So-netと契約した方が安心ですし、接続サービスをSo-netと、回線契約をSo-net経由で行いたいと考えるのは自然なことじゃないでしょうか。
