パスワードを管理する新しい手法「PolyPassHash」が提案される | スラド セキュリティ
パスワードの管理において、「PolyPassHash」と呼ばれる新しい管理手法が提案された（slashdot、論文PDF）。 この手法が提案通りに機能するならば、個別のパスワードを対象としたクラッキングがほぼ無効化されるようだ。またサービスを利用するユーザー側でなにかを変更する必要はなく、パスワードを保存・管理する側（サービス提供側）でこの手法を採用すればいいだけとのこと。 すでにCおよびPythonによる実装も公開されている。 安全性の高さの説明として、「6文字のランダム文字列のパスワードが3アカウント分あったとして、salt＋なんらかのhashで保管されている場合は3つのパスワードすべてをクラックするのに1台のノートPCで1時間ほどの時間しかかからなかったが、 PolyPassHashで保管した場合は地球上の計算機資源をすべて使って宇宙の終わりまでアタックしてもクラックされることはない
数字6桁パスワードのハッシュ値の総当たり、PHPなら約0.25秒で終わるよ
JALの6桁数字パスワード問題から派生して、JALのサイトがパスワードリマインダとして「現在のパスワード」を教えてくれることから、JALサイトではパスワードを平文保存しているのではないかという疑惑が持ち上がっています。それに対して、「いやいや、従来の主流と思われるソルト付きMD5ハッシュでの保存しても、実用的な速度でハッシュ値から元パスワードを『解読』できるよ」と、JALを擁護（?）するエントリが現れました。 パスワード問合せシステムを作る (clojureのreducers) この記事では、最初Clojureによる単純な総当たりで36秒、Clojureのreducersによる並列化で11秒でハッシュ値から元パスワードが求められるよ、と説明されています。まことに痛快な記事ですので、未読の方には一読をお勧めします。 とはいうものの、100万件のMD5の総当たりが、逐次実行で36秒、並列化して
数字6桁の暗証番号が危険なのは総当りで簡単に解かれてしまうから、というわけではない - ただのにっき(2014-02-07)
■ 数字6桁の暗証番号が危険なのは総当りで簡単に解かれてしまうから、というわけではない JALマイレージバンクの不正アクセスが発覚して数日、いろんな人の意見を読んでいるのだけど「数字6桁の暗証番号*1は今どきのPCなら総当りでもすぐに解けてしまうから脆弱だ」という意見がみられて、それはまぁそうなんだけど、今回のような事件に関しては適切な表現ではないと思う。 ちなみに、'000000'から'999999'までバカ正直に順番にMD5を計算し、結果を別途計算してあった正解と比較するプログラムを実行すると、手元の環境ではたった1.5秒しかかからない*2。それでもJMBの会員2700万人分を計算すると450日余りかかることになるが、これだって今どきならクラウドで100コア分調達すれば4日ちょいで解ける計算だ*3。 じゃあやっぱり総当りで解けちゃうから危ないじゃんと思うかも知れないが、この計算が成り立
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
GitHubに大規模な不正ログイン試行 | 徳丸浩の日記
GitHubのブログおよび国内の報道によると、GitHubに対して大規模な不正ログインが試みられたようです。 GitHubは米国時間の2013年11月19日、ブルートフォース攻撃を受けたことを明らかにした。攻撃の時期や被害を受けたアカウント数は公にしていないが、今回の攻撃を踏まえ、より強固なパスワードや二要素認証などを利用するようユーザーに呼び掛けている。 GitHubにブルートフォース攻撃、一部のパスワードが破られるより引用 私もGitHubアカウントがありますのでSecurity Historyページを確認したところ、不正ログインの試行が確認されました。IPアドレスは、ベネズエラ、タイ、ブラジルのものです。 GitHubアカウントをお持ちの方は、念のためSecurity Historyを確認することを推奨します。 今回の不正ログインの特徴は以下のようなものです。 少数の「弱いパスワード
パスワードが漏洩しないウェブアプリの作り方 〜 ソルトつきハッシュで満足する前に考えるべきこと
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
websec-room.com - websec room リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
いまさら聞けないパスワードの取り扱い方
そうだったのか！ よくわかる process.nextTick() node.jsのイベントループを理解するshigeki_ohtsu
IDとパスワードに頼る認証は、もう破綻している
不正アクセス被害のプレスリリースで次のような表現を見るたびに、何ともいえない違和感を覚えてしまう。 「他社サービスにおけるパスワードの使いまわしではない、まったく別のパスワードの再設定をお願いします---」 いや、言いたいことは良く分かる。ユーザーの自衛策として、パスワードの使い回しを避けた方がいいのはその通りだし、その事実をユーザーに啓発することには意味がある。 だが、私が天の邪鬼だからか、記者の職業病ゆえか…この表現には、ユーザーへの責任転嫁のような意図を感じてしまうのだ。 以前の「記者の眼」にも書いたが、インターネットユーザーが「確実に記憶できる」と考えているパスワードの数は、平均で3個ほどだという。「パスワードの使い回しを避けて下さい」というお願いは、実のところ、大半のユーザーには不可能な注文なのだ（関連記事：いくつもの暗証番号、パスワード…もう限界に来ていませんか）。 そもそも、
パスワードリマインダが駄目な理由
昨日、某著名サイトのパスワードリマインダの方式が変更になっていることに気がつきました。 旧: 現在のパスワードをメールで送信する（パスワードリマインダ） 新: パスワード再設定の画面のURLをメールで送信する（パスワードリセット） 新しい方式（パスワードリセット）の方が優れていますが、それでは何故パスワードリマインダは駄目で、パスワードリセットの方がよいのでしょうか。このエントリではその理由について説明します。 パスワードリマインダのリスク 良く指摘されるように、パスワードリマインダの場合、２つの問題があります。 現在のパスワードをメール送信できるということは、パスワードをハッシュ値で保存していない証拠である メールは平文通信なので、パスワードを書いたメールが盗聴されると被害が甚大になる これらのうち、パスワードの保存方法については別稿にゆずるとして、このエントリでは盗聴のリスクについて検
パスワード保存とソルトの話
先日、twitterへのハッキング行為が発見された、という発表がなされました。一部のユーザのデータが漏洩したということです。 この件について個人的に懸念を感じたため、それをこちらに書いておきました。原文では encrypted/salted password と呼ばれていたものが、日本語の公式ブログでは「暗号化されたパスワード」となり、これが朝日新聞では「パスワード」と表記されているという問題です。 専門知識があれば、ここにどういう違いがあるかはわかるのですが、そうでなければわからないのも無理はありません。しかし、わからないからといって省略して良いわけでもありません。パスワードと encrypted/salted password は大きく異なります。 ではどう違うのか？ この話について、ひと通りの解説をしてみるのも良いのではないかな、と思ったのでしてみます。 「パスワード」は保存されない
パスワードは手書きでメモに残せ：日経ビジネスオンライン
この原稿は昨日買ったばかりのiMacで書いている。 例によって、パソコンが壊れたからだ。 いま、「例によって」と書いたのは、事実として、パソコンの死が、私にとって日常の出来事だからだ。 放置しておいた正月の餅にカビが生えるのとまったく同じように、パソコンは、ごくごく日常的にクラッシュする。私は驚かない。どちらかといえば、去年の暮れに金魚が死んだ時の方が動転したかもしれない。 実体験から申し上げるに、パソコンは、あるタイミングで頓死するものだ。あれは、徐々に壊れるような柔軟な機械ではない。天寿をまっとうすることもない。大往生もしない。デジタルのこしらえものは、ある日突然、箱の中のカブトムシみたいに急死する。それも、多くの場合、働き盛りの一番忙しいときに。 とはいえ、注意深く観察していれば、かすかにではあるが、予兆が無いわけではない。 たとえば、ハードディスクがクラッシュする前段階では、ディス
4桁の暗証番号で使用を避けるべき組み合わせとは？ | Token Spoken
この21世紀になっても4桁の暗証番号（PIN）というのは様々な場所で使われています。 欧米などでよく見られるマンション玄関のドアロックから、世界共通の携帯番号のロック機能やATMでの現金引き出しなど、未だに4桁の数字が暗証番号として日常の生活で活躍しています。 たとえば、あなたがキャッシュカードを紛失し、悪意のある人間がそれを拾ったならばどうするでしょうか？ 当然ながら、所有者の生年月日など個人的な数字の組み合わせを知っていればそれを真っ先に試すでしょうが、（最近では生年月日を暗証番号として登録させてもらえませんが。）知らない場合は確率の高い番号を予想して入力するしかありません。 では、そのような非常事態に、悪意のある人間が予想できてしまう暗証番号の組み合わせとは何でしょうか？ iPhoneアプリ「Big Brother Camera Security」のデベロッパーDaniel Amit
(matcha445)まっちゃ445勉強会#14 - Garbage Script on Goo BLOG
第14回 まっちゃ445勉強会 今回もメモレベルですが、ざっと書き記してみたいと思います。 [Session1：「パスワードの話」春山さん](PDF版の資料はココからダウンロードできます) (はじめに) パスワード情報が万が一漏れてしまった時、破られにくくする方法 勿論「パスワードが漏れないようにする事」「ユーザが強いパスワードを付ける事」が前提条件だが Saltを付けてHash化←常識(?) 元ねたは「UNIXのパスワード保存方法」 (UNIX的パスワード保存) GNU/Linuxの場合、/etc/shadowにパスワード情報を保存 (Hashとは) 一方向性、衝突耐性を持っている事 (Saltとは) Hash化の時にパスワードと共に与えられる文字列 ユーザ毎に異なる値が必要←対レインボーテーブル(Ophcrackとかは有名) (ここでFree Rainbow Tableのデモ) (なぜ
メール・FTP・ベーシック認証のパスワードを表示するフリーソフト「SniffPass」 - GIGAZINE
通信内容をキャッチすることによって、POP3・IMAP・SMTP・FTP・HTTPのパスワードを表示することができるフリーソフトがこの「SniffPass」です。「このメールアドレスのパスワードなんだったっけ？」という場合や「FTPのパスワードがわからないので実際に使っているFTPソフトの設定を見たが＊＊＊になって表示されない」という場合に便利です。 パケットキャプチャ用のドライバは「WinPcap」と「Microsoft Network Monitor」が使用可能となっており、「Microsoft Network Monitor」のドライバを使えば無線LANからもパスワードを抜き出すことが可能となります。 というわけで、ダウンロードと使い方は以下から。 ◆有線LANの場合 まずは下記サイトから「WinPcap」をダウンロードします。 WinPcap, the Packet Capture
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
