「ハッシュ」を含む日記 RSS

はてなキーワード: ハッシュとは

2022-08-27

バカエンジニアをはじく面接問題集

ここまでで70%が落ちる

ここまででさらに70%が落ちる

残りの9%にやっとまともな問題を出すことができる

2022-08-14

anond:20220814195229

これか

犯罪者にとって「秘密」とは最高のステーキ

たとえば、同僚が使っているロッカー

番号式のロックがある。

この番号を知ること、かぎつけること、暴くこと、犯罪者にとってこれ以上の美食はない。

ハイエナがうまそうに屍肉に食らいつくのと同じ。

もし「秘密」がない、まともな人間だったらつまらない。

犯罪者人生とは、「仲間」を探し当て、世の中の治安を乱すことが最終目的からだ。

仲間とはもちろん、「心にうしろめたいもの」を持った人間である

番号式のロックや、PCパスワード

これらはそういう仕組みである以上、「秘密」必要とする。

まり犯罪者にとってほぼ唯一の、

一般市民とふれあえる場所」なのである

この秘密を通じて、自分存在意義を確かめることができる。

「ああ、このために生まれてきたんだ」と思える。

まり他人秘密とは、彼らにとって最高のステーキであり、人生を満腹にするためのライフハックなのである

ハイエナサバンナで屍を食らい、むさぼりついている時、

「ああ、生きている!」と感じるだろう。

あれと全く同じである

「三度の飯より、他人秘密

とは犯罪者にとっての人生を見事に表した言葉といえるだろう。

2022-08-14

パスワードを平文で保存しているサービス

舞台演劇チケットを扱っているカンフェティっていうサイト、いまだにパスワードを平文で保存しているんだけど改善してほしい

(「パスワードをお忘れの場合」で問い合わせると登録したパスワードがそのまま表示される)。

危険を感じたのでいったん退会した。

本当は直接企業サイトに問い合わせしたかったんだけど、こちらの名前や連絡先を出したくないので、匿名ダイアリーで書いた次第。

平文で保存というか、平文に戻せる形で暗号化して保存しているのかもしれんね。

httpsなので経路中は盗聴できないとはいえ、適切ではない。

今はパスワードは保存せずにハッシュ化したりして元に戻せない形で保存するのが一般的なので、

何かあった時に流出する危険性はある。

というか、ここで書いちゃったのでハッカーに狙われるかもね。あーあ。ご愁傷様。

anond:20220814195229

平文で保存というか、平文に戻せる形で暗号化して保存しているのかもしれんね。

httpsなので経路中は盗聴できないとはいえ、適切ではない。

今はパスワードは保存せずにハッシュ化したりして元に戻せない形で保存するのが一般的なので、

何かあった時に流出する危険性はある。

というか、ここで書いちゃったのでハッカーに狙われるかもね。あーあ。ご愁傷様。

2022-07-20

anond:20220720094615

ユーザー情報DB攻撃されてハッシュとかソルトとかが流出したときに、

ソルト流出したの?!あり得ない」

ソルト最後生命線なんだからさぁ…」

とか書いている奴らがいて、苦笑するとともに、こいつらがエンジニアやってる会社レベルが知れた。

こいつらの会社サービス利用するほうがありえないわ。

2022-07-08

男は別名保存だから

別名をハッシュにするだけでもgitっぽくなる

女性上書き保存更新履歴が残らない

バージョン管理ができてないからすごい危険

2022-07-02

anond:20220702135854

いうても今どきはbcryptに渡す前にパスワードを固定長化のためにハッシュしとるやろ。

2022-04-13

anond:20220413173659

適当に答えると、パスワード長無制限にすると、それはそれでセキュリティホールになるよね

実際DoS脆弱性回避のために多くのbcryptでは73文字以降は切り捨てられる実装になっているらしい。

パスワードハッシュ化なんて問題は、過去の人発明したよく出来た車輪を使っておけば問題ない。

Webサイトパスワード文字数制限文字制限

Webサイトでの会員登録などでパスワードが求められるが、

パスワード20文字以内まで」 とか、

「半角英数字に限ります」とかで

制限をかけているWebサイト仕様ってどうしてこうなるの(_・ω・)_ババァン!!

バリデーションの境目わかってないどころか、内部で入力パスワードハッシュ化してないんじゃない?

運営者がDB見たら一覧でIDパスワードが生値ででてくるんじゃないの?

運営において生のパスワードがわからないと運用出来ないシステムとかECサイトってなんなんだ?

まりリテラシーが低い開発会社が作っていて、本当にこういうWebサイトって信頼できないから気を付けてください。

他のWebサイトで使っているパスワードがこのWebサイトから漏洩する危険が非常に高いか登録しない方が良いです。

メチャクチャ技術力が低いエンジニアが世の中に鬼のように巣くってるとしか考えられないよ。

こういうWebサイトを取り締まる機関とかないんかな。

匿名しか言いたいこと言えない奴って哀れだよねw言いたいことがあるなら本名で言えwww」

って煽られたから堂々と本名そいつがどんだけクソかをハッシュタグつけてTwitterで長々と投稿したら

次の配信で「こんなにひどいこと書かれた!」ってヘラ配信はじめてなんやこいつってなった。

結局大事なのは匿名本名かじゃないんじゃねーか。

最初から肯定しろって言えよ。

2022-04-12

anond:20220412204851

ネットワークに入り込んでDBデータごと持ってくみたいなことができるならハッシュ化する前のデータを盗み見とかプログラム改ざんもできそうだしさらパスワード頑張っても・・・

現実スーパーハカーがどこまでできるんかよくわかってないけど

2022-03-18

anond:20220316205259

マジレスすると、

ハッシュ(値をバラバラにする処理)→ハッシュポテト→それに付けるのは塩だな→ソルト

という経緯があって本当にポテトだと思ってる

2022-03-17

そもそもハッシュ化の思想を分かってない

暗号化っていうのは

「鍵を知っている人だけが情報を得ることができる」

っていう技術で、ハッシュ化っていうのは

情報の正しさを照合できる」

っていう技術

なので

パスワード暗号化していたら大丈夫

っていうのは嘘で

パスワード暗号化した鍵を大切に保管しているか大丈夫

が正しい

平文を暗号化してサーバに保存している場合は、結局は鍵をサーバに預けているので、信頼情報ユーザの手を離れてしまっている

「めちゃくちゃ厳重に保管しています!!!

って言われても家の鍵を大家に預けているのと同じ状態で家の中に100億円置いてるような人だと信用に足らない

じゃぁ例えばユーザにその鍵を預けておいて、認証の度に渡すようにしよう!なんていうことをやっても

鍵はデジタル情報から簡単コピー可能(追跡不可能)なので一度でも渡したら信用価値ゼロになる

ちなみにこれはハッシュ化でも同じ話で、ハッシュ値をサーバに保存していても平文を送りつけてハッシュ値をサーバ計算していたら意味が無い

ユーザ側でハッシュ値を計算して送りつける方法なら多少は意味があるけれど、結局は鍵がハッシュ値に変わっただけなので通信傍受されたらダメ

なのでダイジェスト認証っていう仕組みを使うので興味がある人は調べて欲しい

ということで、暗号化をしても結局は鍵の扱いに困ることになる

ログインで知りたいのはパスワードのものではなくて「パスワードを知っているかどうか」だけ

なので、ハッシュ化を使って「パスワードを知っていたらハッシュ値も当然知ってるよね・・・?」っていう感じの認証を行う

ここで大事なのはハッシュ化っていうのは秘匿情報ユーザの側にあってサーバ側に渡していない、ということ

なのでプログラムをこねくり回しても原理的には元のパスワードは分からないしそれが基本

そこに「でも単純なパスワード使ってる人がいるかも?」「使い回している人がいるかも?」っていう悪知恵で攻撃してくる人がいるので

ソルトとかペッパーかい小手先防衛してるっていうだけ

あと、秘匿情報ユーザ側にある、といってもどうせスマホとかPCに保存されているのでそっちをクラックされると漏洩する

なので基本的に鍵は脳内に保存した文字列生体認証、もしくはデバイス認証を使う

この辺はパスワードマネージャーを使っていてもマスターパスワード必要になるのと同じ

ここまでがセキュリティ講習の1日目の午前中の話

2022-03-16

anond:20220316202807

前提として、サーバ側のDBの中身が漏洩したと同時に、プログラム設定ファイル、丸ごと全部漏洩したとみなしている。

プログラムDB上のパスワードをどのように処理してるか丸見えになる。

複合できるということは、プログラムの手の届く場所に鍵があるということ。

その鍵がユーザごとに違っていようが関係ない。そのプログラムを通せば複合できるわけだから

複合した結果、元のパスワードを「瞬時に」出せる。

その元のパスワードを使って、正規ユーザのフリをして悪いことができる。

さてハッシュ場合、bcryptなどではソルト付きハッシュ値になってる。

ハッシュ値ごとにソルトが違う構造になってる。

ハッシュなので「時間をかければ」、そのハッシュ値になる値を検索できる。

元のパスワードと同一であるかどうかはわからない。(同一でなければバレる可能性が高まる

1ユーザごとに時間をかける必要がある。

ここである程度時間を稼げるので、サーバ管理者側にサービスを停止したり、パスワードを全部向こうにするような時間の余裕ができる

anond:20220316140745

あーーーほ

そもそも何でハッシュ化が必要なのかわかってないんだろうな。

暗号化しても平分で持ってても、ようはDBアクセスされてる時点でハッキングされてるわけ。

そんなとき暗号化しておくともしかしたらパスワード悪用される前に時間稼ぎができるかもしれん。

でもハッシュならもっと時間稼ぎができる。

そして強力なハッシュ+ソルト+ストレッチングするっていう、「現代デファクトスタンダード」な運用なら一番その時間稼ぎができるわけ。

そもそもDBが完全無欠に守れる自身があるなら平分で保存でもいいわけなんだけど、んなわけねーだろ。万が一流出したときダメージコントロールのためにハッシュカルル訳?ソコンところ理解できてないから、

安全化どうか?みたいなアホな観点しかものを語れないわけよ。アホたれ

からパスワードハッシュおもらししたら、直ちにおもらししたことを報告して、その間にハッシュパスワード解読時間を稼いでる間に、おもらしされたユーザーは万が一他のサービスで同じパスワード使ってるとかいうアホなことしてたら、対応するわけよ。わかる?

まあでも、そもそも他のサービスでもパスワード流用してるタイプのアホは、そんな事しねーよみたいな気持ちもあるな。

そしたらそもそも、平文でほぞんしててもいいような気がしてきたけど、ハッシュ管理してて、アカウントの数が何千万とかあればだよ。

自分アカウントパスワードの解読まで一生かかっても作業が回ってこない可能性もあるので、事実上安全っちゃ安全かもしれない。

でもハッキング対象アカウントが決め打ちでキメられてるなら、スパコンとか使って意地でも特定アカウントパスワードを割り出すみたいな作業可能かもれない。

からってそれは、平文で保存したり、暗号化していい理由には並んと思ってて、

完全に安全パスワード管理することは無理だけど、限りなく安全に近い形で取り扱うことのできるハッシュ化(当たり前だけどそこには強力であること+個別のソルと使うこと+ストレッチングが含まれる)をするのは当然であって、

やっぱりハッシュ化しないって選択肢自体そもそもないので、

ハッシュ安全かどうかとか言ってる時点で、そもそもの何が問題で、なぜハッシュが良いとされているのか、なぜハッシュデファクトで使われているのかってのをまるで理解してないと思う

そうやって表面だけの技術情報をなぞっただけでわかったような気持ち文章書いてる時点で、自分知識に対する過剰な自信と、慢心が溢れ出してて嫌いです

パスワード平文提示のやつ何でダメか教えてほしい

https://www.itmedia.co.jp/news/articles/2203/15/news172.html

ドコモソフトバンクパスワード平文提示問題話題になっていたが、その中のコメント理解できていないのがで教えてほしい。

パスワード暗号化して保持していても、復号できるなら平文保持と同じ」旨のコメントがいくつかあったのだが、これはどういった理由なのだろうか?

暗号化パスワード流出しても、十分な強度を持った暗号化方式を利用している限り、鍵が分からなければ復号できないはずだ(方式によってはIVも)

この鍵が容易に解析できるといっているのだろうか?

それだとPKIの仕組み自体崩壊するので違うような気がする

それとも、サーバで保持しているであろう鍵も盗めるからダメと言っているのだろうか?

そうであればそれは鍵の管理方法次第で、プログラム内に保持しているもしくはユーザ情報(ネットワーク認証コード等)をもとに毎回生成している等であれば問題ないはずだ。

メモリ上の鍵や生成方法も盗まれからダメという話であれば、それはハッシュ化したところで同じ問題が発生するはずだ。

ハッシュ化されたパスワードでも、ソルトストレッチング回数を盗みさえすればある程度時間をかければデハッシュできてしまう。

なんでなんだ・・・教えてエライ

anond:20220316181510

DBファイルが平文でなく暗号化されているということを指摘

これだけで押し通せば間違ってなかったと俺も思うけど

ハッシュだって万全じゃないし!」とか言い始めるのがダサいんだよ

それはみんな知ってる

ハッシュ化さえすれば万全だ」

とは誰も言ってない

anond:20220316180405

そもそもDBファイルが平文でなく暗号化されているということを指摘して、事実報道の誤りを指摘したのが、元コメントだ。

 

それに対して、「正しいデータ保護には暗号化ではなくハッシュ化が必要だ」という方法論を持ち出しているのが、きみたちだよ。全然話の次元が違うだろ。話が噛み合っていない。

 

要するに、人の話を理解できないで、自分の話ばかりをしている。ただのコミュ障だろ。相手が何の話をしているかを知れ。「正しいデータ保護の仕方」というのは、きみの関心であるだけだ。元の話ではそんなことには言及していない。

anond:20220316180017

DBファイル暗号化ファイルが平文ではないという話をしているなら、ハッシュ化の話をするべきだ。ハッシュ化こそが大事であって、これを書かなくては駄目だ。ハッシュ化の話をすれば、それでいい。だけど、レイボーテーブルソルトの話はしなくてもいい」

本当にそう書いてるならそれを引用すればいいのに、さっきから「こう言われた」っていう自分解釈ばっかり

blueboyってほんとしょうもない

anond:20220316175228

> ってことでいい?

全然ダメだね。勝手に歪曲している。(誤読して改変している。)

 

最初コメントは、

DBファイル暗号化ファイルは平文ではない」

だ。これに対して、

 

DBファイル暗号化ファイルが平文ではないという話をしているなら、ハッシュ化の話をするべきだ。ハッシュ化こそが大事であって、これを書かなくては駄目だ。ハッシュ化の話をすれば、それでいい。だけど、レイボーテーブルソルトの話はしなくてもいい」

 

ときみたちが言っているから、

ハッシュ化だけじゃ駄目だよ。レイボーテーブルソルトまでやらないと、十分ではないよ」と教えてから、「だけどブコメでは字数制限があるんだから、書けなくても仕方ないね。それはおたがいさまだよ」

と教えて上げている。

 

なのにきみたちは、「100字以内で ハッシュ化と レイボーテーブルと ソルトまでわかりやす説明しないやつは、ど素人だ」と文句を言っているんだよ。自分のことを棚に上げて。

anond:20220316175037

ハッシュ化すれば万全だ」とは誰も言ってないのに、「ハッシュ化しても安全とは言えない」ってキリッと反論したつもりになってるってことでいい?

anond:20220316174110

> たとえ話のこのくだりは、どれに当たるんだ

コメントだと明示してあるだろ。元記事の次のコメントだよ。引用すると:

> 「平文を個別提供する」からといって、「パスワード全体を平文で保持している」ことにはならない。保持データには暗号化されている。

ここにハッシュ化の話が含まれていないと文句を言っているのが、きみたちだよ。見当違い。

ログイン ユーザー登録
ようこそ ゲスト さん