NIST Special Publication 800-63 Revision3

パスワードは定期的な強制的な変更を行うべきではないと記載されている文書。(変更しなくて良いとは書いていない)
パスワード運用の見直しのきっかけにもなっている。

日本語訳はIPAから出ていないので、世界の電子認証基準が変わる:NIST SP800-63-3を読み解くNIST SP 800-63-3の概要と今回の改訂がもたらす影響を参照するとよい。

原文はこちらから参照できる。

SSL Server Test

日経NETWORK 2018年9月号より

米クリオスのSSLラボが提供するSSLチェックツール
https://www.ssllabs.com/

財テク.jpというサイトをチェックしたところレーティングはBでKey Exchangeに問題があるとの判定だった。

B判定の主な原因として、下記3点があった。
This server uses SSL 3, which is obsolete and insecure. Grade capped to B.
SSL3に対応している。

This server accepts RC4 cipher, but only with older protocols. Grade capped to B.
ChiperにRC4が利用できる。

This server does not support Forward Secrecy with the reference browsers. Grade capped to B.
Foward Securityに対応していない。。。。

一方で、HSTSに対応している点は評価された。
HTTP Strict Transport Security (HSTS) with long duration deployed on this server.

SSL対応状況について

Chorome68からSSLに対応していないサイトは警告されるようになった。
「日立製作所も対応していないからといって、当社も対応する必要がありません。」
という会社があるとしたら、ホームページの重要性について理解されていないと思わざるを得ない。。。。

利用者視点で言えば、HSTSに対応していないというのもいただけないのだが、なぜSSLの対応にこれだけ腰が重いのかが理解に苦しむ。。。。

Mailsploit

Fromヘッダにヌルバイトが含まれるとSPF,DKIM,DMARCを採用して、送信元が詐称されたメールを拒否できるように対応していたとしてもクライアントメールソフトで送信元が詐称されたメールが届いてしまうように見える問題。
メールソフトが正しくヌルバイトを取り扱い出来ない場合には、送信元が正しく表示されないことで詐称されたメールと勘違いして中身を開いてしまう点が深刻である。

Mailsploitは何が脅威なのかを考えてみるに詳しく記載されている。

gpg(GNU Privacy Guard)

鍵の生成

$ gpg –gen-key

初めて鍵を生成する際にはかなりの時間を要する。応答がないので、ハングアップしているようにみえるが、辛抱強く待つ必要がある。なお、鍵の生成を自動化する場合には、予め設定ファイルを作成の上、
$ gpg –batch –gen-key (設定ファイル)
とする。2048bitの公開鍵(RSA)設定ファイルの書式例は、下記のようになる。

%echo Generating a basic OpenPGP key
 Key-Type: RSA
 Key-Length: 2048
 Subkey-Type: RSA
 Subkey-Length: 2048
 Name-Real: (Real Name)
 Name-Comment: (コメント名)
 Name-Email: (メールアドレス)
 Expire-Date: (有効期限)
 Passphrase: (パスフレーズ)
 %commit
 %echo done

公開鍵の確認

$ gpg --list-keys

秘密鍵の確認

$ gpg --list-secret-keys

公開鍵のエクスポート

$ gpg --export -a '(gpg --gen-keyで指定したReal Name)' > エクスポートファイル名

鍵(公開鍵、秘密鍵共通)のインポート(エクスポートした鍵を他の環境にてインポートする)

$ gpg --import (エクスポートファイル名)

鍵の検証

$ gpg --fingerprint -a '(gpg --gen-keyで指定したReal Name)'

鍵の信頼

$ gpg --sign-key -a '(gpg --gen-keyで指定したReal Name)'

※–batch オプションはうまくいかなった

ファイルの暗号化

$ gpg -e -r (gpg --gen-keyで指定されたメールアドレス) (暗号化したいファイル)

暗号化したファイルには、.gpgという拡張子が付加される。

gpg –gen-keyで指定されたメールアドレスが同一となっている公開鍵がある場合には、最も古い鍵が使用されるようだ。鍵を指定したい場合には、–list-keysで表示される鍵のIDを代わりに使用するようにした方がよい。(鍵が更新される前提で、余り気にしないでもよいようになっているようだが、調査が必要)

ファイルの復号

$ gpg (暗号化されたファイル)

管理している鍵より対応する秘密鍵にて復号される。

鍵の失効

$ gpg --output (作成する失効証明書ファイル名) --gen-revoke -a '(gpg --gen-keyで指定したReal Name)'

作成された失効証明書をインポートすると、公開鍵が使用できなくなる。(秘密鍵自体は有効なので、公開鍵を使った暗号化はできないが、失効証明書をインポートする前に暗号化されたファイルを秘密鍵を使って復号することは可能)

鍵の削除

$ gpg --delete-secret-keys (鍵ID)
$ gpg --delete-keys (鍵ID)

鍵を削除する際には、秘密鍵を同時に管理している場合には、秘密鍵を先に削除する必要がある。

参考)

秘密鍵のエクスポート

$ gpg --export-secret-key -a '(gpg --gen-keyで指定したReal Name)' > エクスポートファイル名

参考サイト

gpg (GNU Privacy Guard)の使い方

gpgでのファイルの暗号化基礎

gpgで秘密鍵を作成する

鍵の自動生成(オフィシャルサイト/英文)

クラウドサービスで割り当てされるIPアドレス

クラウドサービスで割り当てされるIPアドレスは一度ブラックリストに載っていないかチェックしてから運用した方がよさそう。
前の所有者の悪い行いでブラックリストに登録されていると、メールが届かないとか、いろんなトラブルに巻き込まれそう。。。
TrendMicro
Symantec
ブラックリストのデータベースの信頼性も疑わしい。もう少ししたらレピュテーションサービスの意図的なフォルスポジティブによって、インターネットが支配される日が来るかもしれない。

NASで稼働しているSambaの脆弱性対策について考える

バッファローのNAS LS210D0301のファームウエアのバージョンアップ通知があったので、何の修正かと思ったら、1ヵ月以上前に報告されていた
CVE-2017-7494 Sambaの脆弱性により、リモートから任意のコードが実行可能な脆弱性
の対応だった。もう少し早くならないものか。。。。
もうすでに販売終了品だし、周辺機器メーカからすれば、どこまでサポートしなきゃいけないんだという話も出てきそうな内容だが。。。。
というか自分もこのCVEの情報を把握していなかったのも問題だし、NASがSambaで動いているという推測が働かないのもまずいなぁ。。。。と反省。

個人情報のオプトアウト

会員登録しているジェームスのDMが先日届き、よく見たところ裏面に提供された個人情報をカーディーラに提供する
提供することに同意できない場合には、連絡してください
といった趣旨の記載があった。
個人情報提供者が、本人の同意を得ることなく第三者に個人情報を提供するのは個人情報保護法に違反するのでは?
と思って調べてみました。
結論としては、個人情報保護法23条2項に明記されている例外的に個人情報の第三者提供(販売)できるオプトアウトという手法に該当しており、
手続に問題なければ違法ではないというのが見解のようだ。
DMが家に届く=送付元に個人情報を提供している
ということなので、DMは捨てないでよく見ておかないとオプトアウトされる恐れがあり、本人の意図に反して、個人情報が拡散するという怖いリスクがある。
本人の要求があった場合に第三者提供を停止する運用を行っている
といっても、第三者に提供済みの個人情報は削除されるかどうかはかなり怪しい。。。。
まとめると、(当たり前の話だが)個人情報を提供するのは最小限にとどめておいた方がよいということだ。
改正個人情報保護法でオプトアウトの手続はどう変わったか
個人情報販売の適法要件(オプトアウト)