• ベストアンサー

金融機関ではパスワードは平文管理ですか?

ある証券会社でパスワードが分からなくなったため、通知の依頼をしたところ、教えて貰えました。 ただ、振り返って考えてみると、書留ではありましたが、登録したことのあるパスワードがそのまま届きました。 金融機関では、ハッキングなどセキュリティを高める目的でパスワードはハッシュで格納してあり、パスワードそのものは保存していないと思っていたのですが違うのでしょうか? 一般に金融機関ではハッシュではなく平文で保存されているのでしょうか?

質問者が選んだベストアンサー

  • ベストアンサー
回答No.4

まあ、詳しいことは内緒ってことで。 でも思い出せば数年前までは平文・可逆暗号のところも結構あった気がする。 今も同じシステムを使ってれば。。。そういうことですね

remixiii
質問者

お礼

回答いただきありがとうございます。 数年前ですか・・・金融庁など公的な機関から、ある程度指針や指導などがあり守られていると何となく強度の強いセキュリティで守られていると思っていましたが、そうでも無さそうですね・・・ 一点聞きたいのですが、証券会社と銀行ではセキュリティ強度について差はありましたでしょうか?もし、秘匿事項外でしたら教えていただければ幸いです。最近は、この二者の垣根が無くなってきており、区別の難しい銀行もいくつかあります。セキュリティの考え方について大幅な差があれば、考えたいと思っています。

その他の回答 (5)

  • lv4u
  • ベストアンサー率27% (1862/6715)
回答No.6

>>特に、バイオメトリックなどですと、一度流出すると二度と変更ができませんし、大変なことになると思うのですけどね・・・ バイオメトリックの場合は、サーバの保存データを使うというよりも、その方の目玉をくり抜いて持っていく、指を切り落として持っていくという方向で悪用されるのではないでしょうか?もしくは、指紋を特殊素材で再現する方法もあるらしいですね。 いまのところ、その系統では、あまり心配は無いと個人的には思います。 それよりも、現実問題としては、中国のサイバー攻撃のほうが重要だと思いますね。初歩的とはいえ、DDos攻撃もそれなりに有効ですし、スピア型攻撃をされれば、もっと危ないですよね。昨年のサイバー攻撃では、攻撃元の解明に時間がかかりましたし、日本は、中国軍のサイバー攻撃に対して、全く反撃をすることができなかったようです。 まあ、自衛隊のサイバー空間での交戦規定がどうなっているのか、知りませんが・・・。 もう中国とはサイバー空間では戦争状態にあるといえますから、私としては、こっちのほうが心配です。

remixiii
質問者

お礼

回答いただきありがとうございます。 静脈、指紋ですと、一度盗まれると、変更ができず、偽造技術は進歩し続けますので、一度情報を取られると、今すぐというよりも、死ぬまで不安が残る気がするのですよね・・・ サイバー攻撃については、自衛隊ではこれからハッカーを雇うという話がニュースになっていましたし、銀行については、中国ではありませんが、丁度今アメリカが大変なことになっている最中ですので、これからの指標になりそうですね。ただ、先の不可逆の暗号化であれば、仮に盗まれたとしても、その物が盗まれるのとは違いますから、他への被害は限定的だと思うのですけどね・・・

  • lv4u
  • ベストアンサー率27% (1862/6715)
回答No.5

No.2です。 >>そう言う意味の平文ではありません。 「不可逆な」という意味を含めての平文ってこと?普通は単に暗号化されていないという文を「平文」って言うと思いますが・・・。 >>普通の金融機関では、暗号担当?の担当者も分からないようになっているはずなのです。詳しくは、ハッシュ関数とかそんな感じの意味です。 別にハッシュ関数とは関連なくてもいいではず。不可逆なパスワードが生成されればいいわけですね。 まあ、会社によって、いろいろでしょうから、不可逆じゃあないパスワードを使っているところがあっても不思議ではないと思います。 ちなみに、某銀行の場合、そのあたりのロジックは、別の部門で管理されていて、他のロジックのようにソースは見せてくれなかった。

remixiii
質問者

お礼

回答いただきありがとうございます。 良い用語が分かりませんでしたので、例と共に質問めさせていただきました。分かりづらい文章ですみません。 最近の流出事件を見ると、暗証番号がそのままでていったと言うことは、ありますが、その度に、一方向関数?ハッシュ関数?について聞きましたので、銀行や証券会社レベルであればどこも厳格に管理しているのかと思って質問させていただきました。 特に、バイオメトリックなどですと、一度流出すると二度と変更ができませんし、大変なことになると思うのですけどね・・・それでも、やはり、そのままの形で保存している物でしょうか?

回答No.3

パスワードは不可逆ですね 設計レベルで知っているのは3社ほど

remixiii
質問者

お礼

回答いただきありがとうございます。 やはり、ハッシュ保存が基本ですよね。因みに、それは全て銀行でしょうか? 実は、金融機関と言っても、証券会社でして銀行と同じように強固なセキュリティを考えていると思っていたのですが、違うのでしょうか?もしよろしければ、分かれば教えていただけると幸いです。 ちょっと前に合併してシステムも強化されたと思われる中堅どころの証券会社でこういったことがあり不安に思っています。

  • lv4u
  • ベストアンサー率27% (1862/6715)
回答No.2

>>登録したことのあるパスワードがそのまま届きました。 暗号化して保存していたパスワードを、復号して送ってくれたのではないですか? 平文では、保存していないでしょう。 そして、プログラムを使えば、元のパスワードを知ることができますよね?そうじゃあなければ、ログオン時にパスワードチェックできないですから。

remixiii
質問者

お礼

回答いただきありがとうございます。 そう言う意味の平文ではありません。普通の金融機関では、暗号担当?の担当者も分からないようになっているはずなのです。詳しくは、ハッシュ関数とかそんな感じの意味です。

回答No.1

まあその金融機関はずさんな情報管理ですね。。。 私が知っている限りの金融機関は暗号化してます

remixiii
質問者

お礼

回答いただきありがとうございます。 回答者様は、SEでしょうか?また、ご存じの金融機関で、その暗号化というのは、可逆性のものでしょうか?それとも、ハッシュのように不可逆な物でしょうか? また、知っている限りと言うことですが、具体的に、何社程度そんな感じでしょうか?

関連するQ&A

  • ユーザーパスワードのDBの格納について

    あるメーカーのソフトウェアを使用しており、Webからログインするときのユーザ名、パスワードがユーザーデータベースのテーブルに平文で格納されています。 そのソフトで使用しているデータベースはSQL Server 2008R2になります。 平文で格納されているのが気になっており、SQL Server 2008R2を使用してテーブルに格納するパスワードをハッシュ+ソルト+ストレッチングして格納すること仕組みとして可能かどうか気になっております。 もし仕組みとして可能な場合、Webからログインした際にユーザーが入力したパスワードをハッシュ+ソルト+ストレッチングして、テーブルに格納されているハッシュ+ソルト+ストレッチングしたパスワードと比較して認証を行うようにプログラミングは可能でしょうか。

  • PHP PEAR AUTH 認証でのパスワードを忘れた場合

    AUTHを利用しての、認証を行う場合、usernameとpasswordの カラムを持つテーブルを参照しますが、このpasswordは MD5でハッシュした値で、テーブルに格納しなければならないようです。 この場合、パスワードを忘れてしまった際など、テーブルを 見てすぐにpasswordの値が確認できないので不便です。 なのでテーブルに格納するパスワードは平文としたいと思います。 平文でpasswordを格納しても、'cryptType'=>"none"とすれば 認証は通りますが、やはり平文では心配な所があります。 良い解決方法があれば教えてください。

    • ベストアンサー
    • PHP
  • phpのパスワードのハッシュ化について

    phpで会員サイトの作成を学習しています。 PDOを使用してMysqlサーバーに接続しています。 開発環境はxamppでphp Version 5.5.15を使用しています。 入力フォームにユーザーの情報を入力してもらい、 データベースに格納する際、 基本的なセキュリティ要件として パスワードをハッシュ化する必要があるということを こちらのサイトで(http://php.net/manual/ja/faq.passwords.php) 知りました。 ハッシュ化については初耳で、いまいちハッシュアルゴリズムの種類による違い等はまだ理解しきれていないのですが、 PHP5.5.15を使用しているので、パスワードのハッシュアルゴリズムは 上記サイトに載っているようにpassword_hashを使用するのが今のところ最善なのでしょうか? また、ハッシュ化されたパスワードの認証についてですが、 ログイン画面でパスワードを認証する際、 ユーザーが入力したパスワードをハッシュ化して 該当レコードのハッシュ化されて保存されたパスワードと 同じであれば認証が成功するという認識で正しいでしょうか? ご回答、よろしくお願いします。

    • ベストアンサー
    • PHP
  • ストレッチング

    こんにちは。 今日、パスワードに関する記事を読みました。 パスワードというのは平文で保存しないで、代わりにハッシュ関数を施した値を保存して、これらの値が漏えいしても元のパスワードが解読されないようにしているみたいです。そして「ストレッチング」というのは、このハッシュ計算を何回も施した値を保存するのだそうです。 そこで、質問です: パスワードの保護に関して「十分に安全なハッシュ計算」(そういうモノがあるとして)の冪乗は、再び「十分に安全なハッシュ計算」になるのでしょうか。 よろしくお願いします。

  • 金融機関の口座名義人死亡の場合の口座封鎖について

    金融機関の口座名義人が死亡した場合、死亡が金融機関に伝わると、 とりあえず、口座が封鎖され、預金などが下ろせなくなりますが、 この名義人死亡情報は、どのように、金融機関に伝わるのでしょうか。 名義人の家族、親族が伝えなければ、何時までも伝わらない? それとも、どこか公の機関が死亡通知を金融機関に出す? それとも、・・・・・ ご存知の方お教えください。 間もなく、今話題(?)の住民基本ネットが本格的に稼動するようになると 金融機関に自動的に伝わるようになる? 追加:証券会社も銀行などと同じく、封鎖されるのでしょうか。

  • 任意整理の「事故情報」は金融機関にどのように流れていくのでしょうか?

    この度弁護士さんに依頼して任意整理をすることになりました。そこで教えていただきたいのですが、任意整理をすると、まず、信用情報機関に「異動情報」として登録されるらしいのですが、その詳細(弁護士に任意整理を依頼した事)まで異動情報に掲載されるのでしょうか?また、この情報は私が任意整理を依頼していない他のその他金融機関(自動車のローン契約を結んでいる信販会社等)に自動的に流れていくのでしょうか?それとも、あくまでも金融機関等が必要に応じて個別に私を特定して確認をしなければそのまま情報としてはわからないのでしょうか?アドバイスをお願いします。

  • パスワードのsaltの構築方法

    PHPでパスワードの登録でsaltを使用しようと考えているのですが、ネットで調べても自分の疑問に思っている事が出てきません。 パスワードにsaltという十分な長さ(40文字とか)の文字列を加え、それをmd5などでハッシュ化する・・・と言うことは分かりました。 しかしその実装方法が分かりません。 A.saltはランダム乱数でもいいし、セキュリティは低くなるが固定文字列でもいい。 B.saltは別ファイルに保管(一緒に保管と書いてあるのもありましたが)する。 、というような記事を見かけました。 で、自分はZendFrameworkのマニュアルに沿って考えたのですが、 データベーステーブルにpassword、saltカラムを作成する。 登録時、$_POST['ユーザの入力値']を(ハッシュ化する)passwordカラムに、saltはここでは単純にmt_rand(0,99)としてsaltカラムに登録、とした場合に認証時にはどのようにすればいいのでしょうか? 認証時にユーザの入力したパスワードとデータベースに格納したsaltを結合し、それをmd5()したものと、データベースに格納されているパスワードと同じく格納されたsaltを結合しそれをmd5()したものを比べる ・・・となるとパスワードさえ合って入ればいいので別にsaltは不要なような気がするのでこの実装法は間違っているのかなと思います。 そうではなく、登録時にユーザの入力したパスワードとデータベースに格納したsaltを結合し、それをmd5()したものをpasswordカラム又はsaltカラムに格納する・・・というのも正しいのかな?と思います。 データベースに侵入されればどちらもダメなので、何か別ファイルに保管するのかなとも思いましたが良く分かりません。 登録フォーム => ログインフォームにおいてのsaltの実装法を教えていただけないでしょうか?少し頭がぐちゃぐちゃになり、ちょっと文章がおかしい気もしますがすみません。

    • ベストアンサー
    • PHP
  • 外資系金融機関が大阪証券取引所で取引するためには?

    私の主人はアメリカ人で米国の証券会社でトレーダーとして働いてますが、彼の会社が大阪証券取引所の取引に参加したい(自己売買業務のみ)とのこと、私に相談してきました。 外資系金融機関(中小証券会社)が大阪証券取引所に登録?するためには、やはり日本で法人化、もしくは支店を立ち上げなければならないのでしょうか? また、どのような手続きを取ればいいのか教えていただけると幸いです。

  • Yahoo! ユーザ・パスワード流出について

    ユーザ ID だけではなく、1 百万超ユーザのパスワードが漏れていたらしいことを発表しましたが、 これはパスワードのいわゆるハッシュ・リストなのでしょうか。それ以上のことが書かれていないので、何ともわかりません。 それとも、平文のリストでも存在して、それが流出したのでしょうか。 前者の場合は辞書攻撃や総当たりの「事務的」手続きが簡略化されるだけで、さして問題とならないような気がしますが、万一後者なら、なぜそんなリストが存在するのでしょうか。 スーパユーザが一般ユーザのパスワードを知る必要なんてどこにも存在しない(SU は何でもできるので)と思いますが、管理者がそんなものを保存する意義は何かあるのでしょうか。

  • パスワードハッシュ化時の乱数のsaltについて

    パスワードのハッシュ化について | http://okwave.jp/qa/q6377700.html で質問したものです。 ユーザー登録するwebサイトを構築する予定です。パスワードはsaltをつけてsha256でハッシュ化して保存しようと思っています。 saltはランダムにしたほうが良いとの情報を得ましたが、ログイン認証をする際にそのsaltがわからなければならないと思います。ランダムなsaltはDBに保存してしまうんでしょうか?それとも他の項目(登録日時など)をキーにハッシュ化したものを使う、とかですかね? ランダムなsaltの管理方法を教えてください。 ※ asp.net(C#)とoracleで構築予定です。