ソルト付きハッシュのソルトはどこに保存するのが一般的か - Qiita
pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた（中略）パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。（それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。） 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
ブロックチェーンでそんなことはできない - chike0905の日記
概要 本稿は、突然ムシャクシャした筆者が自分の考えるブロックチェーンの定義と、世間で言われているブロックチェーンの特性および応用例を批判するものである。 本稿は筆者の見解であり、所属組織の公式見解ではない。 ブロックチェーンの定義 そもそもブロックチェーンとはなんなのか。狭義には、「ブロック」の「チェーン」であることから、以下の定義をしたい。 データが、当該データ直前のデータの暗号学的ハッシュ値を持つリスト型のデータ構造 ここでは、そのデータの中に何を保持するかは一切考慮しない。 データがハッシュ値で連鎖することによって、リスト中の任意のデータのみを書き換えると、ハッシュチェーンの整合性が失われ、書き換えが行われたことを検知可能なデータ構造であると定義する。 しかし、世間で「ブロックチェーン」に興味を持つ諸氏はこの定義だけではいささか狭すぎると感じるだろう。 そこで、狭義のブロックチェーン
JWT認証、便利やん？ - ブログ
どうして JWT をセッションに使っちゃうわけ？ - co3k.org に対して思うことを書く。 (ステートレスな) JWT をセッションに使うことは、セッション ID を用いる伝統的なセッション機構に比べて、あらゆるセキュリティ上のリスクを負うことになります。 と大口叩いておいて、それに続く理由がほとんどお粗末な運用によるものなのはどうなのか。最後に、 でもそこまでしてステートレスに JWT を使わなくてはいけないか？ とまで行っていますが、JWT認証のメリットはその実装のシンプルさとステートレスなことにあります。現実的には実際はDB参照とか必要になったりするんですが、ほとんど改ざん検証だけで済むのは魅力的です。トレードオフでリアルタイムでユーザー無効化ができないことくらいですかね。ライブラリなんて使う必要ないほどシンプルだし、トレードオフさえ許容できればむしろ、なぜこれ以上に複雑な認証
MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？ - Quora
回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...
ID生成大全 - Qiita
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ - エンジニアHub｜Webエンジニアのキャリアを考える！
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
「低要求での品質逆転の法則」というのを思いついた - きしだのHatena
つまり、ソフトウェアのあらゆるパラメータで、要求が低いときには工夫をしないほうが品質が高くなるという法則。 たとえば、アルゴリズムというのは理論的にはデータが増えたときに性能悪化がゆるやかなもののほうがよいということになってる。 でも多くの場合で、よいアルゴリズムは、少ないデータ数では単純なアルゴリズムに負ける。ソートなんかだと、データ数が一定以上のときはクイックソートだけどデータ数が少ないときはマージソートを使うということがよく行われる。「指数時間」かかると言われるアルゴリズムは遅くて使い物にならないということだったけど、それをがんばって「多項式時間」という使い物になるはずのアルゴリズムに改良したら複雑になりすぎて、通常のデータ数なら「指数時間」のアルゴリズムよりも遅いということがよくある。 データの格納にしても、データベースは便利だけど、データ数が少ないときは単純なテキストファイルのほ
ランキングのつくりかた:Kenn's Clairvoyance
遅ればせながら、あけましておめでとうございます。 先週には、ベイエリアの友人たちがやっているEchofonがPostUpに買収されるなど、幸先のよい新年のスタートとなりました。 さて、最近ホットなマーケットといえばソーシャルゲームですが、ゲームといえばリーダーボード。ハイスコアのランキングで友人や見知らぬ人たちと競うのは、ビデオゲームが誕生した1970年代から欠かせない要素でした。 ところが、インターネット経由で100万人規模のプレイヤーがつながるようになってきた現在、その全体をランキングづけするのは、技術的にも大きなチャレンジとなってきました。 今回は、そのリーダーボードのつくりかたについて、ぼくらの作っているソーシャルゲーム・プラットフォームであるPankiaの運用で得られた知見を共有したいと思います。 自分の順位を知る方法 リーダーボードの基本的な考え方はシンプルで、それはつまり「ユ
SHA1でハッシュ化したパスワード - teracc’s blog
SHA1でハッシュ化したパスワードは危険になった - yohgaki's blog を読みました。その記事に関連したことを書きます。 ハッシュアルゴリズムの切替え 記事を読んで思い出したのは、既にパスワードをハッシュ化して保存していて、そのアルゴリズムが脆弱になった場合に、いかにアルゴリズムを切替えるかという問題です。 ハッシュデータは元に戻せないため、アルゴリズムを切替えるのも難しいのです。 パスワードはどうやって持つ？ - がるの健忘録 パスワード暗号処理変更用 大雑把草案 - がるの健忘録 上記の日記で、この問題を扱っています。その日記の中では、 ユーザがログイン成功した際に、システム側でパスワードが判る。 その際に、DB保存データを新アルゴリズムの形式にする。 という方式が提案されています。この方式では、システム更新後に、ログインしたユーザから順次新しいアルゴリズムになります。ログ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
Webアプリケーションにおけるパスワードの管理について
[帰ってきた] koboストアの品揃えを見守るページ