ランダムな文字列を生成するワンライナー
openssl rand -base64 10 | tr -dc 'a-zA-Z
【GCE】【gcloud】いま、どのプロジェクトなのかbashのプロンプトに表示する
複数のGCE環境を掛け持ちしていると、どのプロジェクトで作業しようとしているのか分からなくなるので
どのプロジェクトがアクティベートされているかをプロンプトに表示します。
以下を ~/.zshrc とか ~/.bashrc に追記
function get_active_gce_group { if [ -f ~/.config/gcloud/active_config ]; then cat ~/.config/gcloud/active_config else echo "--" fi } export PROMPT="%{$fg[green]%}(gcloud:$(get_active_gce_group)) $PROMPT"
でファイルを読み直したら反映されます。
$ source ~/.zshrc
gcloud confing configurations コマンドでconfig設定を切り替えについてはこのへん を参考にどうぞ。
Apple ID のパスワード変更方法 【秘密の質問を忘れた時】
Apple ID のパスワード変更するには、【秘密の質問】に応える必要があるのですが、その【秘密の質問】を忘れてしまったときのパスワード変更方法を紹介します。
Apple ID のパスワード変更方法 【秘密の質問を忘れた時】
以下のリンクに既存のID/パスワードでログインすれば、パスワードリセットのリンクがApple ID に送られてきます。
マクニカネットワークス、日本を襲った大規模な攻撃キャンペーンを分析した「標的型攻撃の実態と対策アプローチ 第1版」を公開
本レポートでは、マクニカネットワークスが2014~2015年に多く観測されたEmdiviと呼ばれるRAT(Remote Access Trojan)が用いられた攻撃キャンペーンを分析し、攻撃者が使う手法(TTPs = Tactics, Techniques, and Procedures)と、標的型攻撃に従来からよく見られるTTPs、そして企業の成熟度に応じた対策の考え方を解説しています。
とのことです。
詳細なレポートは以下のページからダウンロード可能です。
パスワードに文字数制限があるサイトはヤバイ
パスワードに文字数制限があるのは、つまりデータベースのカラムに文字数制限がある。
したがって、平文で保存している可能性が高い。
ぼくのかんがえたさいきょうのパスワード管理
ちまたでは【パスワードの定期変更は意味がある/ない】の議論がつきませんが、みなさまいかがお過ごしでしょうか。
自分なりに満足の行くアカウント管理ができつつあるので、紹介したいと思います。
モットーは【簡単かつセキュアに】
こうやりたい。しかも簡単に。
実現したいのはこんなアカウント管理です。
- スマホでもPCでも同じように管理する
- メールアドレスを登録するサイト毎に変更する
- パスワードを登録するサイト毎に変更する
- 可能な限り、20文字以上で大文字小文字数字記号が入り乱れたものにする。
- あんまりブラウザのパスワード記憶に頼りたくない。
いやいや、無理やん。
面倒くさい。
メールアドレスとか何個作らなあかんねんと。
パスワード、覚えられるわけがないと。
けど、できちゃうんです。相当楽に。
用意するもの
用意するものは3つだけです。
- Gmail
- Dropbox
- keepassx
なぜ、google アカウント?というのは後述します。
GmailはGoogle の提供するメールサービス、 Dropbox はファイル共有サービスです。
keepassx はオープンソースのパスワード管理ソフトです。聞き慣れないアプリかもしれませんが、MacでもWindows でもLinuxでも使えるすぐれものです。
Mac 製品しか使わないって人はkeepassx の代わりに、1Password がいいと思います。(Androidのクライアントもあるようです)
ぼくのかんがえたさいきょうのパスワード管理
登録時
サイトに登録するときは次のようにしています。
メインのメールアドレスをcameong@gmail.com とします。
- keepassx のデータベースをDropbox につくる (初回だけ)
- メールアドレスを
cameong+"ランダムな文字列"@gmail.com
で登録する - パスワードを20文字以上のランダムなものを作る
- メールアドレスとパスワードとサイトドメインをkeepassx に保存する。
- Dropbox を使う端末(PC, スマホ)で連携する
ランダムなパスワード生成は mac だと pwgen
などを使うといいでしょう。
--- 追記 2016/7/2 ---
keepass に標準のパスワード生成機能があるようです。
こちらも便利ですね!
追記ここまで
注意点としては
- アカウント情報の更新をする端末を決めておきましょう
- じゃないとkeepassx のデータベースが壊れるかもしれません
- すくなくともiPhone はkeepassxのデータをデバイス内に保存してるので、リアルタイムに同期はしていません。
- ぼくはPCで更新するようにしています
- 【追記】↑リアルタイム同期しているとの報告も受けました。設定によって変更できるかも。
- keepassx に鍵をかけるか暗号化しましょう
- サイトのドメインも忘れずに登録しておきましょう
ログイン時
サイトにログインするときは、すごく簡単です。
- ログイン画面に行く
- keepassx を開く
- サイトのドメインを検索し
- id, password をそれぞれkeepassx からコピペする
おしまい。簡単ですね。
PCでもスマホでも同じアクションでログインできます。
解説
すこし、解説します。
cameong+"ランダムな文字列"@gmail.com
はちゃんと自分のところにとどくのか?
はい、届きます。
Gmailの仕様でメールアドレスのローカルパート(@より前) の+
以降は無視され、+
より前のメールアドレス宛に届きます。
ですので、cameong+"ランダムな文字列"@gmail.com
は全て cameong@gmail.com
に届く寸法になります。
もし、Gmail 以外に同等の機能のあるメールサービスがあれば、なにを使っても大丈夫です。(あったら教えて下さい)
--- 追記 2016/7/2 ---
@icloud.com も同様の機能があるようです。( from id:takuya_1st )
追記ここまで
パスワード忘れた時
パスワードを忘れた時、通常であれば、パスワードリセットフォームからメールアドレスを入力するのですが、この方法だとメールアドレスを記憶しておくのは無理です。
基本的にはkeepassxにどのサイトをどのメールアドレスを利用しているか保存してあるはずなので、keepassx を見れば大丈夫です。
もし、keepassx に書きわすれていた時は、、、Gmailで登録したサイトのドメインを検索してください。
(普通であれば)登録したメールアドレス宛にアカウント有効化のメールが届いているはずなので
- 有効化のメールを探す。
- To アドレスを調べる。
この方法で登録アドレスがわかると思います。
なぜメールアドレスをサイトごとに変更するのか
メールアドレスに+hash を足してサイトごとの登録メールアドレスを変えているのは、【登録しているサイト以外にメールアドレスを知られたくない】ためにおこなっています。
たとえば、
- サイトAで
cameong+AAA@gmail.com
のメールアドレスを登録 - サイトBで
cameong+BB@gmail.com
のメールアドレスを登録
していたとします。
もしサイトAのメールアドレスとパスワードが流出した場合、サイトBのメールアドレスを検知するのは困難ですので
サイトBと称してcameong@gmail.com
宛にメールが送られてくると怪しいわけです。(サイトBからはcameong+BB@gmail.com
宛に送られてくる。)
ソーシャルハッキングがますます増えている昨今では、+hash は一定の効果があるのではないかと思います。
パスワード流出の二次被害防止のために、最低限でもサイトごとに異なるパスワードを登録してください。
2段階認証
大本のメールアドレスを他人に乗っ取られてしまうと↑でやったことが意味なくなってしまいますので、2段階認証を使って強固にしましょう。
ぼくは2段階認証のクライアントにauthy を使っています。
はじめはauthenticator を使っていたのですが、登録できる端末が1つしか無いので、もしその端末が水没したりすると終わるので、複数デバイスで利用可能なauthy を利用しています。
(authentiator でも端末が使えなくなった時のためにリカバリープランはあるのですが、面倒くさくて)
運用しながら、管理方法を改善しています。
こんな管理方法があるよ!などありましたら、コメント欄等でおしえてください。
それでは、よいパスワード管理ライフを!
--- 追記 2016/7/2 ---
keepass より高機能なパスワード保存アプリには次のようなものがあります。
1Password
Dashlane www.dashlane.com
どちらもマルチデバイス対応しているようなので、試してみたいと思います。
追記ここまで
Google Cloud Storage をnginx でhttpsで公開する
Google Cloud Storage(GCS) は独自ドメインでファイルを公開する機能が付いているが、http のみしか対応していない。 https で対応するには以下のようにnginxでプロキシするなどの方法を取る必要がある。
config
画像用ドメイン: static.kmn.jp バケット名: static.kmn.jp (※ https化にはlet's encrypt を利用しているため、そのための設定も入っている。)
$ cat /etc/nginx/conf.d/static.kmn.jp # Cache 10GB for 1 Month proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=GS:10m inactive=720h max_size=10240m; upstream gs { server 'storage.googleapis.com:443'; keepalive 100; } server { set $my_domain "static.kmn.jp"; server_name static.kmn.jp; ### # <tls setting> ### listen 443 ssl; # nginx 1.9.5 以降の場合 # listen 443 ssl http2; server_name static.kmn.jp; server_tokens off; ssl_certificate /etc/letsencrypt/live/static.kmn.jp/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/static.kmn.jp/privkey.pem; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; # 環境によっては off にすると動かないので注意 (default は on) ssl_session_tickets on; # 2048bit 推奨 ssl_dhparam /etc/ssl/private/dhparam.pem; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; ### # </tls setting> ### # Logs access_log off; error_log /var/log/nginx/static.kmn.jp.error.log error; # Cache Control expires max; add_header Cache-Control "public, max-age=31536000"; # Nameserver resolver 8.8.8.8 valid=300s; resolver_timeout 10s; # Proxy Cache proxy_temp_path /tmp/nginx; proxy_cache_lock on; proxy_cache_key "$uri"; # Ignore Parameters ## https://github.com/FRiCKLE/ngx_cache_purge #proxy_cache_purge on from 127.0.0.1; # Limit Request Methods to GET|HEAD|PURGE if ( $request_method !~ "GET|HEAD|PURGE" ) { return 405; } location / { proxy_set_header Host storage.googleapis.com; proxy_hide_header x-goog-hash; proxy_hide_header x-goog-generation; proxy_hide_header x-goog-metageneration; proxy_hide_header x-goog-stored-content-encoding; proxy_hide_header x-goog-stored-content-length; proxy_hide_header x-goog-storage-class; proxy_hide_header x-xss-protection; proxy_hide_header accept-ranges; proxy_hide_header alternate-protocol; proxy_hide_header Set-Cookie; proxy_ignore_headers "Set-Cookie"; proxy_intercept_errors on; proxy_cache GS; proxy_cache_valid 200 720h; # Cache For 1 Month proxy_cache_bypass $http_cache_purge; add_header X-Cache $upstream_cache_status; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_pass https://gs/$my_domain$uri; } } # let's encrypt の自動更新用の設定 server { listen 80; server_name static.kmn.jp; location '/.well-known/acme-challenge' { default_type "text/plain"; root /tmp/letsencrypt-auto; } location / { return 301 https://$server_name$request_uri; } }
設定反映
sudo service nginx configtest && sudo service nginx reload