アカウント名:
パスワード:
近頃同じような問題が発見されたようです https://it.slashdot.org/story/18/05/02/0613205/github-accidentally-exp... [slashdot.org]一部のユーザが対象のようですGitHub からメールを受け取って知りました (巧妙な釣りかとおもいました)
ニュースを読んで、Twitter開いて、パスワード変更して、再ログインとなって、警告が現れた。この警告、効果あるのかな。
Twitterの公式アプリは、「パスワードが一回入力されたら、そこからAPIトークンを発行して以後はそれを使う(APIトークンは https://twitter.com/settings/applications [twitter.com] から取り消したりアカウントを消去などのことをしない限りパスワードを変えたりしても一生使える)」という実装なはずなので、パスワードがアプリ内で保持されているわけでも変更したパスワードがアプリに同期されているわけでもないはずです。
まともなサービスはそういう実装してるはずだけど、割と普通にローカルにパスワード保存してるアプリあるのよね・・・Twitterなんかはアプリ開くと基本すでにログイン状態のようなもので、入力は求められないけど、その都度入力を要求する作りのアプリとか、TouchIDで認証求めてパスした後に、パスワードを自動入力する、という実装。特に日本の(ITじゃない)大企業のアプリはどれもひどいね。WebView多用だし。
まともなサービスはそういう実装してるはずだけど、割と普通にローカルにパスワード保存してるアプリあるのよね・・・
日本国内の某IT系企業にいますが、業務システム刷新のときに「パスワードはハッシュ化して保存しなくていいんですか？」って上長に聞いても「え？なんで？暗号化すればいいでしょ？」だったからなぁ。
# そのシステムで顧客ユーザーの信用情報とかマイナンバーとか扱ってる会社なのでAC
ハッシュ化と暗号化が別物であると分かってもらえてるだけまだマシですよ…。
# 当然AC
昨日パスワード変更したら、連携アプリの確認も求められた気がする。iOSアプリとの連携を止めたければ、その時に中止にすれば良かっただけだと思う。
＃自分は久しぶりに連携アプリの大掃除をした。こんなに利用していたのね……
「アカウントセキュリティに関するお知らせ」と言うメールが来てましたが「ハッシングと呼ばれるプロセル」など日本語がなんともおかしい相当に質の悪い機械翻訳でしょうかこの記事を見るまでフィッシングメールだと思ってました
あんな家賃の高いビルにオフィス置いて翻訳者一人も雇えないのか
その詫び老人って、給与いくらなんですかねえ引き抜きたい会社がいっぱいあるのでは
あんなひどい対応をさせるくらいだ歩合制と言われても驚かない。
急いでるからですかね～。
さっきモバイル版にアクセスしたら、ハッシュのことをマスクとか書いてて、なるほど一般人にはそっちの方が分かりやすいかもなと感心しました。
少しずつ対応を改善しているのかもしれないっすね。
一般人には、どっちも均等にわからないのでは。
漏洩センサーとしてこのまま使っていようと思う。
使い回ししていたら、twitterのパスワードだけ変更しても効果のある対策にはならないですね。
今回のアナウンスは、twitter社内の内部犯の存在を疑ってくださいというメッセージなんでしょうが、ぶっちゃけそのタイプの攻撃に対してはそもそも一般利用者は抵抗のしようがないしパスワード変える意味あんの？とはちょっと思う。件のバグを情報を抜くために故意に仕込む人物の存在をユーザーが疑っても始まらない。
まあリアルに考えると、本番環境でもログは相対的に緩い権限でアクセスできるシステムになっていて悪用があった時の容疑者の特定が困難(だから普段の条件では信用できる社員でも魔が差すことがあるかも)で、若干リスクが上乗せされてるからってことなんでしょうが。
欧米の会社は社員を信用していないこの手のセキュリティリスクに対応するために暗号化アルゴを開発する人と、データを運用する人は分けてる暗号化アルゴを開発する人達は、Twitterの内部ログの生データにはアクセスできないようにされてるしデータを運用する人達は、暗号化されたあとのデータしか触れないだから、生データがそのまま保存されてる自体ってのは本来想定してないんだよ日本企業はその辺なあなあで済ますところが多いから信用されないけど
そういう意味では、「bcrypt関数でハッシュ化している」ということなので
暗号化アルゴリズムは、そもそも自社開発していない。
自社開発した暗号化アルゴリズムとか怖すぎて使えるわけがない。それこそ従業員がこっそりバックドアを仕込んでいてもまったく不思議はないな
いや欧米は関係ないでしょ。
それなりの企業ならヒラの開発者は実環境のログにはアクセスできない体制にしてる。でも開発者と監視者が手を組んだら不可能も可能にできる。所詮人を完全に信用しない運用なんて成立しないよ。
同じくつか、Twitterのアカウントに使ってるメアドも捨てアド扱いのものなんで漏れたら漏れたで面白そうｗ
「2要素認証を有効化すること」も推奨している割には、手続きのためのメール送付が「新規メールアドレス登録時」にしかできない造りのままなあたりからもなんだか全体が見通されてないシステムという印象がします。新規アカウントを作る人にとっては問題ないけども。
本当にTwitter内部のログだったら、内部で削除すればいいんじゃないの？なんでエンドユーザに対応を求めるの？
"内部"と安全性をアピールしてるけど、短期のカスタマエンジニアとか下請けとかの"ほぼ外部"の人間の目に触れる状態だったんじゃないの？
こういう事言うやつがいるから隠蔽体質が生まれるんだな。
本当に信用できるTwitter社員のみが閲覧できる状態なら該当ログを削除するだけで良いのでは、と思った次第。隠蔽とかじゃなくて、単に「不要な作業をユーザに求めないで欲しい」と思ったんです。
もし信用できない部外者が閲覧できる(可能性がある)なら、「内部ログ」とか安全アピールせずに「情報漏洩した」と言えば良くない？
あんたの言う「内部」「外部」ってのはどういう意味なんだ？平文のパスワードを見れた可能性のある人間がいるのなら、そいつが社外の下請けだろうが現社員だろうがすでに退職した元社員だろうが、悪用されてユーザーに被害を与えたり会社の信用を失墜させる恐れが1%でもあるのなら、万が一を考えて傷が浅いうちに正直に報告してユーザーに対策してもらうのが賢明な判断だと思うがね。
てか、「パスワードが不正に使用された兆候はみられない」って兆候ってのはこれから起こりそうな前触れって意味なんだが
万が一のことを考えてじゃないの？
RoRは最初期から、 password という名前のPOSTパラメータは、デフォでログに描き出す時にマスクする対象になってるので、scalaで再実装した時に漏れたのかな…
議事録みたいに最初から記録しなければ良いんだね
> 早稲田卒のエリート違和感あるなぁ…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
GitHub でも (スコア:5, 参考になる)
近頃同じような問題が発見されたようです https://it.slashdot.org/story/18/05/02/0613205/github-accidentally-exp... [slashdot.org]
一部のユーザが対象のようです
GitHub からメールを受け取って知りました (巧妙な釣りかとおもいました)
再ログイン後に警告 (スコア:2)
ニュースを読んで、Twitter開いて、パスワード変更して、再ログインとなって、警告が現れた。
この警告、効果あるのかな。
ちょっと怖かったのは (スコア:2)
iOS側も変更しなきゃなあと思いTwitterアプリを起動したら
パスワードが同期されていて普通に起動したこと
アプリ連携が動作していたので同期されたんだろうなあってことに･･･
なんか怖かった
Re: (スコア:0)
Twitterの公式アプリは、「パスワードが一回入力されたら、そこからAPIトークンを発行して以後はそれを使う(APIトークンは https://twitter.com/settings/applications [twitter.com] から取り消したりアカウントを消去などのことをしない限りパスワードを変えたりしても一生使える)」という実装なはずなので、パスワードがアプリ内で保持されているわけでも変更したパスワードがアプリに同期されているわけでもないはずです。
Re:ちょっと怖かったのは (スコア:2)
逆にこのようなAPIトークンを実装しているソフトが少ない印象を受けました
Re:ちょっと怖かったのは (スコア:1)
まともなサービスはそういう実装してるはずだけど、割と普通にローカルにパスワード保存してるアプリあるのよね・・・
Twitterなんかはアプリ開くと基本すでにログイン状態のようなもので、入力は求められないけど、
その都度入力を要求する作りのアプリとか、TouchIDで認証求めてパスした後に、パスワードを自動入力する、という実装。
特に日本の(ITじゃない)大企業のアプリはどれもひどいね。WebView多用だし。
Re: (スコア:0)
まともなサービスはそういう実装してるはずだけど、割と普通にローカルにパスワード保存してるアプリあるのよね・・・
日本国内の某IT系企業にいますが、業務システム刷新のときに「パスワードはハッシュ化して保存しなくていいんですか？」って上長に聞いても「え？なんで？暗号化すればいいでしょ？」だったからなぁ。
# そのシステムで顧客ユーザーの信用情報とかマイナンバーとか扱ってる会社なのでAC
Re: (スコア:0)
ハッシュ化と暗号化が別物であると分かってもらえてるだけまだマシですよ…。
# 当然AC
Re: (スコア:0)
昨日パスワード変更したら、連携アプリの確認も求められた気がする。
iOSアプリとの連携を止めたければ、その時に中止にすれば良かっただけだと思う。
＃自分は久しぶりに連携アプリの大掃除をした。こんなに利用していたのね……
Re:ちょっと怖かったのは (スコア:2)
WindowsRTで使ってたマイクロソフトとかの連携はこの際削除しました
# コンセプトとか好きだったのになあ･･･ RT
日本語が変 (スコア:1)
「アカウントセキュリティに関するお知らせ」と言うメールが来てましたが「ハッシングと呼ばれるプロセル」など日本語がなんともおかしい
相当に質の悪い機械翻訳でしょうか
この記事を見るまでフィッシングメールだと思ってました
Re: (スコア:0)
あんな家賃の高いビルにオフィス置いて翻訳者一人も雇えないのか
Re: (スコア:0)
その詫び老人って、給与いくらなんですかねえ
引き抜きたい会社がいっぱいあるのでは
Re: (スコア:0)
あんなひどい対応をさせるくらいだ
歩合制と言われても驚かない。
Re: (スコア:0)
急いでるからですかね～。
さっきモバイル版にアクセスしたら、
ハッシュのことをマスクとか書いてて、
なるほど一般人にはそっちの方が分かりやすいかもな
と感心しました。
少しずつ対応を改善しているのかもしれないっすね。
Re: (スコア:0)
一般人には、どっちも均等にわからないのでは。
使い回ししていないから (スコア:1)
漏洩センサーとしてこのまま使っていようと思う。
Re: (スコア:0)
使い回ししていたら、twitterのパスワードだけ変更しても効果のある対策にはならないですね。
今回のアナウンスは、twitter社内の内部犯の存在を疑ってくださいというメッセージなんでしょうが、
ぶっちゃけそのタイプの攻撃に対してはそもそも一般利用者は抵抗のしようがないしパスワード変える意味あんの？とはちょっと思う。
件のバグを情報を抜くために故意に仕込む人物の存在をユーザーが疑っても始まらない。
まあリアルに考えると、本番環境でもログは相対的に緩い権限でアクセスできるシステムになっていて
悪用があった時の容疑者の特定が困難(だから普段の条件では信用できる社員でも魔が差すことがあるかも)で、
若干リスクが上乗せされてるからってことなんでしょうが。
Re:使い回ししていないから (スコア:1)
欧米の会社は社員を信用していない
この手のセキュリティリスクに対応するために
暗号化アルゴを開発する人と、データを運用する人は分けてる
暗号化アルゴを開発する人達は、Twitterの内部ログの生データにはアクセスできないようにされてるし
データを運用する人達は、暗号化されたあとのデータしか触れない
だから、生データがそのまま保存されてる自体ってのは本来想定してないんだよ
日本企業はその辺なあなあで済ますところが多いから信用されないけど
Re: (スコア:0)
そういう意味では、「bcrypt関数でハッシュ化している」ということなので
暗号化アルゴリズムは、そもそも自社開発していない。
Re: (スコア:0)
自社開発した暗号化アルゴリズムとか怖すぎて使えるわけがない。それこそ従業員がこっそりバックドアを仕込んでいてもまったく不思議はないな
Re: (スコア:0)
いや欧米は関係ないでしょ。
それなりの企業ならヒラの開発者は実環境のログにはアクセスできない体制にしてる。
でも開発者と監視者が手を組んだら不可能も可能にできる。
所詮人を完全に信用しない運用なんて成立しないよ。
Re: (スコア:0)
同じく
つか、Twitterのアカウントに使ってるメアドも
捨てアド扱いのものなんで漏れたら漏れたで面白そうｗ
2要素認証を有効化することを推奨している…？ (スコア:0)
「2要素認証を有効化すること」も推奨している割には、
手続きのためのメール送付が「新規メールアドレス登録時」にしかできない造りのままなあたりからも
なんだか全体が見通されてないシステムという印象がします。
新規アカウントを作る人にとっては問題ないけども。
内部ログ (スコア:0)
本当にTwitter内部のログだったら、内部で削除すればいいんじゃないの？なんでエンドユーザに対応を求めるの？
"内部"と安全性をアピールしてるけど、短期のカスタマエンジニアとか下請けとかの"ほぼ外部"の人間の目に触れる状態だったんじゃないの？
Re:内部ログ (スコア:1)
こういう事言うやつがいるから隠蔽体質が生まれるんだな。
Re: (スコア:0)
本当に信用できるTwitter社員のみが閲覧できる状態なら該当ログを削除するだけで良いのでは、と思った次第。
隠蔽とかじゃなくて、単に「不要な作業をユーザに求めないで欲しい」と思ったんです。
もし信用できない部外者が閲覧できる(可能性がある)なら、「内部ログ」とか安全アピールせずに「情報漏洩した」と言えば良くない？
Re: (スコア:0)
あんたの言う「内部」「外部」ってのはどういう意味なんだ？
平文のパスワードを見れた可能性のある人間がいるのなら、そいつが社外の下請けだろうが現社員だろうがすでに退職した元社員だろうが、悪用されてユーザーに被害を与えたり会社の信用を失墜させる恐れが1%でもあるのなら、万が一を考えて傷が浅いうちに正直に報告してユーザーに対策してもらうのが賢明な判断だと思うがね。
てか、「パスワードが不正に使用された兆候はみられない」って兆候ってのはこれから起こりそうな前触れって意味なんだが
Re: (スコア:0)
万が一のことを考えてじゃないの？
脱railsしたときかな? (スコア:0)
RoRは最初期から、 password という名前のPOSTパラメータは、デフォでログに描き出す時にマスクする対象になってるので、scalaで再実装した時に漏れたのかな…
Re: (スコア:0)
議事録みたいに最初から記録しなければ良いんだね
Re: (スコア:0)
官僚にパワハラしても言いっぱなしで
議事録なんか作らないから無問題
Re: (スコア:0)
> 早稲田卒のエリート
違和感あるなぁ…