目次
2019-07-23 のみかい
2019-07-20 夏休みとフェス
2019-07-14 パスワードの管理方法（令和元年版）
2019-07-12 いきてますよ
2019-06-19 飲み会二つ
2019-06-14 google photos その後
2019-06-12 Google drive バックアップと同期
今月の日記
いちいち飲み会に行った、なんて報告書く必要ないのだけど、普段はめったに飲まないもので。
僕は主夫を標榜しているし、実際子供が保育園の頃は、出かけられなかった。
誘われても飲み会なんていけなかった。
それが、最近は出かけられるようになったタイミングで、たびたび友人から誘われるようになったので参加している。
というわけで、セガ時代の知人と飲んできた。
同期が僕含めて３人。
コラムス 97 の企画者と、ダイナマイト刑事の国内担当者だな。
それと、テクサポの時の課長と、企画課の先輩。
企画課の先輩は一緒に仕事をしたことはなかったと思うが、よく知ってはいる人。
元課長とあったのは、たぶん１５年ぶりくらい。
今回はいなかった同期の結婚式の時にあった。
ダイナマイト刑事担当と、企画課の先輩は、その数年後にもう一度会ったと思う。
コラムス 97 企画者は今でも時々あっている。
彼はいろんな方面で昔の知り合いとつながっていて、今回は彼が集めたメンバー。
今でもセガ社員なのは、元課長とダイナマイト刑事担当。
課長は役職についているのかと思いきや、プログラムしているのが好きだというので今でも現役プログラマだそうだ。
あの人どうなっている？ 的な話題では、思ったより多くの人がまだセガにいた。
何度も分社したり組織変更したりで、そのたびに「誰が辞めた」という話を聞いてきたので、もうほとんど残ってないかと思ってた。
僕が凄腕プログラマだと思っていた３人…一人は課長なのだけど、ST-V BIOS 書いた先輩もまだ残っているらしい。
一番の凄腕だ、と思っていた人は、とっくにやめているのを知っている。
先に書いた、同期の結婚式の時に会い、その時点で辞めているのを知った。
この凄腕氏のその後を知りたいのだけど、消息不明なようで誰も知らなかった。
楽しかったのだけど、早めに帰らねばならず、皆がまだ話している最中に抜けてきた。
とはいえ、抜けた時間は１０時半。
僕は家が遠いし、主夫なので朝５時半に起きる必要がある。
なんとか、家には当日中に帰り着いた。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
子供たちが夏休みに入った。
今年の夏は、初夏のころにずいぶんと暑かったが、その後の梅雨はめっきり冷え込んだ。
日照量不足は、1993年…「平成の米騒動」以来の少なさだそうで、東京では２０日連続で３時間以下。
平均気温では、1988年年の記録的冷夏以来、だそうだ。
まぁ、そんな気候での「夏休み」が、どうもピンと来ない。まだ夏が来ていない気がする。
今年は、長男が中学３年生で受験生なので、夏も塾の予定がみっちり入っていて忙しい。
夏の家族旅行は今年は行かない予定。少ない休みを旅行で疲れさせるようでは、子供がかわいそうだから。
その代わりといっては何だが、近場でのんびり楽しめるところがあれば行きたいと思っている。
さて、夏休みに入ると同時…というか、その前日から、スプラトゥーン２の全世界同時ファイナルフェスが始まっている。
フェスでは、たびたび料理が争点となるフェスが行われていた。
そのたびに、僕は唐揚げを作ってレモンを用意したり、ポテトにマヨネーズとケチャップを添えたり、パイナップル入りの酢豚を用意してきたりした。
今回もフェスだから何か料理作って、と子供に頼まれていたのだが、今回のテーマは「混沌 vs 秩序」だ。
料理にはできない。
…と思ったら、子供に「ロブの店風のごはんにしたい」と言われた。
ロブの店かぁ。
スプラトゥーン２の中に出てくる、入手したチケットで飲み食いできる店で、食べたものにより、その後しばらく経験値ボーナスが入ったり、獲得金額が増えたりする効果がある。
この料理の絵面が…まぁ、見た人はわかるだろうが、すごいのだ。
基本的には、エビフライを中心とした料理。
（スプラトゥーンは、すべて海の生物の世界観だ。店の主人のロブ自身がエビフライに見える）
エビフライを挟んだホットドック風の「ロブサンド」が基本。
豪華になると、ベルギーワッフルでエビフライを挟んでホイップクリームをデコレーションした「あげホイップ」や、エビフライでソーセージを挟んだ「ギャラクシーサンド」など、わけのわからないものになる。
まぁ、冗談としては面白いのだけど、どう料理するか。
とりあえず、エビフライは基本。家族五人で２０本用意した。
ギャラクシーサンドがあるのだから、ソーセージも用意した。
ロールパンに切れ目を入れたものと、ホットドック用の長いパン、ハンバーガーのバンズも用意した。
ベルギーワッフルは、なし。用意しようと思えばできるが、甘いものが入るとすぐおなか一杯になってしまい、楽しめない。
あとは、各自が好きな形に挟んで食べる、ということで。
我が家では、時々こうした形式での「サンドイッチパーティ」をやっている。
それを、スプラトゥーン２風にできる素材でやってみた、というだけ。
今日で最後？ のスプラフェスめし。
— wizforest (@wizforest) July 19, 2019
子供のリクエストでロブサンドなのだが、材料用意したので自分で好きに作るスタイル。 pic.twitter.com/dBZcTYXyNn
キャベツの千切りも用意した。
スプラに出てくるロブサンドには緑色のものが入っている…と思ったら、よく見ると野菜ではなくて、チューブから絞り出したような形をしている。
あ、これきっと、ワサビだ。
しかしまぁ、ワサビは合わなさそうなのでキャベツの千切りで。
＃アボカドを使ってグヮカモーレを作れば、合う味で似た見た目にできるかも。
ホイップクリームの代わりに、ホイップした、エビフライに合うソースを用意。
卵を白身と黄身にわけ、白身を泡立て、メレンゲにする。
泡が消えないように、少しだけ砂糖を入れる。（甘くする目的ではない）
黄身は、ニンニク、レモン汁、オリーブ油を加えて激しく混ぜ、こちらも少し空気を含ませたアイオリソースに。
＃アイオリソースは、マヨネーズの原型となったソース。ニンニク入りマヨネーズだと思っていい。
で、メレンゲとアイオリを混ぜ、泡が消えないようにさっくりとなじませる。
エビフライにタルタルソースが合うように、このソースはちゃんと合う味だった。
ただ、ホイップしたので量が多くて、半分以上余った。
翌日、スクランブルエッグに混ぜて食べた。
（元が卵だから、普通にスクランブルエッグにできる。ふわふわになったけど）
以下おまけ。
過去にフェスご飯をした時のツイート。
第１回 2017年 8月4日、「マヨネーズ vs ケチャップ」
第４回 2017年 11月11日、「からあげに レモンかける vs レモンかけない」
第２５回 2019年 6月15日、「酢豚にパイン ナシ vs アリ」
スプラのフェスは終わったが、我が家のフェスはこれからだ。
— wizforest (@wizforest) September 10, 2017
ちなみにディップはケチャとマヨ。 pic.twitter.com/AVQdJyS45s
夕飯できた。からあげwithレモン。
— wizforest (@wizforest) November 11, 2017
ポテトに、ケチャマヨもある。
ちなみに、料理中に遊んでた子供は、スーパーレモンかけるボーイと、ふつうのレモンかけないガールになった。 pic.twitter.com/gCwzvFC0XN
やっとでけた。
— wizforest (@wizforest) June 15, 2019
実は本格的な酢豚作ったのは初めて。
試食したがちゃんとうまい。 #スプラフェス pic.twitter.com/pSF21tjudR
これ以外にも食べ物ネタのフェスはあったのだけど、基本的に「おやつ」に属するものだったので、買ってきて食べただけです。
（でも、我が家ではフェスの時はそれに関連した食べ物を用意してました）
ポッキーフェスの時は、フェスのお題だったポッキー・ポッキー極細に加え、トッポやフランも買ってきて豪華なおやつでした。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
５年も前に書いた記事に、ご意見をいただいた。
記事の間違いを指摘してくれたものだ。
以前からたびたび書いているが、僕は自分の知識が正しいとは思っていない。
５年も前の記事なら状況も変わっているだろうからなおさらで、こうした指摘はありがたい。
しかし、今回に関してはどうもご指摘がおかしいように思えた。
最新の情報では変わっていたりするかも…と念のため調べたが、今でも僕の書いた記事は有効なようだ。
どうも、ご指摘が勘違いからくる誤りのようだが、一人ご指摘をくれたということは、それ以上に多くの人が同じような勘違いをしているように思う。
そのため、過去の記事の内容を解説し、指摘がどう誤っているのかを記しておく。
まず、過去記事の概要。
パスワードは紙に書いてはダメで、すべて記憶するのが正しい、と思っている人が多いことに対して、その間違いを指摘した記事だ。
（これも5年前の話なので、今でもこう思っている人は減っている、と思いたい）
パスワード管理する上で、重要なのは
・サイトごとにすべて変更する。
・ほぼランダムに見える文字列を使う。
・時間的にも時々変更する。
の３点で、これらの決まりを守ろうとすると、パスワードを記憶する、というのは難しくなる。
そのため、20世紀には、「パスワードは紙に書かず、記憶するのが正しい」とされた時代はあるが、現代においては紙に書くのは悪い手段ではない、と解説したものだった。
これに対して、いただいた意見は「時間的な変更」をやってはならない、とするものだった。
時間的に変更することを促すと、パスワード管理が雑になり、セキュリティが弱くなる、という指摘だった。
この指摘は、2017 年に NIST （米国国立標準技術研究所）が勧告したパスワード管理方法を踏まえたものだろう。
僕の記事は 2014 年に書かれたもので、情報が古くなり意味を失った、と捉えることもできる。
NIST は、米国政府関連で求められる認証方法について、時代に合わせて適切なセキュリティ強度を保つための勧告をまとめている。
2017 年の報告では、パスワードを設定する際のユーザーインターフェイスなどについてもまとめている。
ここには「パスワードの変更を強要すべきではない」という趣旨が書かれている。
これを受けて、国内でも総務省が「安全なパスワード管理」という呼びかけページを作成した。
ここに、パスワードの「定期的な変更は不要」と書かれている。
これがちょっと問題ありで、見出しに大きな文字で「定期的な変更は不要」と書かれてしまった。
内容を読むと、変更が不要なのではなく、「パスワードの定期的な変更を要求すべきではない」と書かれている。
この内容自体、 NIST の勧告に基づくものだ、と書かれていて、趣旨も同じだ。
あくまでも「変更の要求」に問題があるとするものだ。
しかし、見出しに「定期的な変更は不要」と書いてしまったために、多くの人が勘違いしてしまった。
新聞報道などでも「パスワードは変更しない方が良い」として広まってしまった。
NIST の勧告はセキュリティのためだけではなく、ユーザーの利便性を考えて「システムによる行き過ぎた規制」を緩和しようとしているものだ。
パスワード変更を強要すべきではない、という文脈には、「異なる文字種の混合を要求したりしてはならない」というものも入っている。
異なる文字種…数字、大文字、小文字、などだ。
この３つを、それぞれ少なくとも１つ以上は使うように求めるシステムは結構多い。
それらを混ぜることで、セキュリティが高まると期待しているのだ。
しかし、NIST はこれを禁じている。
ここにあるのは「ユーザーに不便を強いるな」という意図であり、セキュリティ強度とは無関係の話だ。
（一応、文字を混ぜても期待するほどセキュリティ強度は上がらない、という解説が巻末についているけど）
以上のように、NIST 勧告の「時間的な変更をやってはならない」は、システムに組み込むべきではないという指針だ。
それに対し、僕が過去記事に書いたのは、各ユーザーが自発的にとるべき、パスワード管理の心得を書いたものだ。
これらは全く性質の異なるものだ。
しかし、今回いただいたご指摘は、これを混同したものだった。
異なるものを混同し、「パスワードを変更してはならない」と考えていると、セキュリティ上のリスクを生じてしまう。
なぜ時間的な変化が必要かを示そう。
単純な話、パスワードはいつか破られる。
もちろん、攻撃側にその気があれば、の話だけど。
攻撃者がパスワードを知る方法なんて、いくらでもある。
たとえば、パスワードハッシュファイルの入手。
詳細は５年前の記事を参照してほしいが、攻撃者がパスワードハッシュを入手した場合、比較的「覚えやすい」パスワードなら、解明されてしまうだろう。
覚えにくい…ランダム文字列は、解明を遅らせることができる。
だから、「ほぼランダムに見える文字列を使う」という指針が入ってくる。
その一方で、キーロガーと呼ばれるような手段を使い、あなたが入力するパスワードを「直接」記録する方法もある。
この方法で奪われた場合は、キー入力がそのまま漏れてしまうため、文字列がランダムに見えるかどうかは関係ない。
あとは、パスワードが「漏れた」前提の話となる。
被害を最小限に食い止めるためには、そのパスワードが使える場所を限定しておくことだ。
「サイトごとにすべて変更する」というのは、そのための指針となる。
では、最悪の状況、実際に被害が出たとしよう。
問題は、それがどのような被害だったか、ということだ。
「勝手に買い物」された場合は、身に覚えのない請求が届くので気づくだろう。
しかし、メールなどを覗き見られて生活を丸裸にされている場合には、パスワードが漏れたと気づくだろうか？
時間的に変化させる、というのは、こうした気づかない被害に対する防御策だ。
大規模なパスワード流出があった、というような状況では、世間的にもパスワードの変更が呼び掛けられる。
パスワードが「漏れたかもしれない」と思えば、変更しておくのが良いだろう。
が、ストーカー被害の場合は身近な人によるショルダーハッキング…あなたが会社の PC などを操作しているときに、後ろからパスワードを覗き見ただけ、などの可能性がある。
キーロガーすら使わない。パスワードは、漏れるときは本当に簡単に漏れる。
そうした状況では、自分のパスワードが漏洩した、と気づくのは難しい。
NIST では、「第三者のログインに気づくようなシステム」を構築することも推奨している。
そうしたシステムなら、パスワードが漏洩し、情報を覗き見られていることにも気づくかもしれない。
しかし、残念ながらそうではない WEB サービスが多い。
ここでの自衛策は、時々パスワードを変えることだ。
普段から時々パスワードを変える、という習慣を持っていれば、パスワードが第三者に知られたとしても、被害をある程度の範囲で食い止めることができる。
「時間的にも時々変更する」というのは、そのための指針だ。
ただ、ここでいう「変更すべき」なのは、ユーザー各自の裁量に任されていることに気を付けてほしい。
先に書いた通り、NIST は「変更を強制すべきではない」とするだけで、この件についてあまり触れていない。
しかし、「強制的にパスワード変更を促す」システムは弊害しかない、というのはセキュリティ専門家の多くの意見が一致するところだ。
定期的に変更すべき、と言われて自主的に変更するユーザーは、セキュリティ意識が高い。
当然、変更の際にも妥当なパスワードを設定するだろう。
しかし、特にセキュリティ意識がなく、パスワードを「面倒だけど設定しないといけないもの」程度にしか思っていない人の場合、頻繁に変更を繰り返すと、覚えやすい単純なパスワードに収束していく傾向がみられる。
変更しろ、と言われたから、最初は 1234 に。次は abcd に…という具合に。
最初の設定ではそれなりに強度のあるパスワードを使っていたとしても、より弱いものに変えさせる「強制」は、百害あって一利なしだ。
（ちなみに、NIST の勧告では、abcd や 1234 といった「連続文字」パスワードは設定できないようにしなくてはならない、と示されている。
これらは、ユーザーの利便性を最大限に考慮したうえでも、設定されるべきではないパスワードだ）
過去の記事に指摘をくださった方が「時間的な変更を促すと、パスワード管理が雑になる」と言っているのは、このことだろう。
同じ「時間的な変更」であっても、システムが強制するのと、ユーザーの自発性に任せるのとでは意味が違う。
この二つを混同してはならない。
強制はしてはならないが、時間的な変更はされるのが望ましいのだ。
話はこれで終わりだ。
NIST 勧告の「変更を強制すべきではない」はずいぶんと勘違いされていて、パスワードを変更してはならないのだと思っている人が増えているようだ。
強制すると雑になるから、というのは、ご指摘の通りだと思っていい。
多くの専門家がそう指摘している。
また、NIST 勧告では書かれていないものの、「わざわざ書かないだけ」で、前提にしている気がする。
一方、今回指摘を受けてネットを調査していたら、「パスワード変更の際に、変更しようとしているパスワードがネットワークを流れることになるから危険」と言う主張も見た。
変更自体が危険なのだと思っている人は、こうした話を「裏付け」として信じてしまうかもしれない。
しかし、たいていパスワードは暗号化通信（SSL）を使って通信されるから、覗き見られることはない。
「暗号化も破られるかもしれない」という前提に立つのであれば、ログインするたびに通信されるパスワードのほうが、変更のために１度だけ入れられるパスワードよりも、ずっと危険性が高い。
この危険度を下げるためには、同じパスワードでログインされる回数を減らせばよい。
つまり、時々パスワードを変更すべきだ。
結局、「変更の危険性」を主張しようとして変な前提を持ち出しても、むしろ変更すべきだという話になる。
さて、以下は余談。
わずか2週間前に、セブンイレブンが新しい電子マネーである「7pay」を導入しようとして、大失敗をやらかして、炎上した。
最大の大失敗は、システム側でのパスワード認証が「ざる」だったことだ。
本人の生年月日を答えられれば、任意のメールアドレスに対してパスワードの再発行を要求できる、というシステムがあり、生年月日を設定していない場合の日付初期値が固定だった。
このため、アカウントの ID さえ割り出せれば、高確率でパスワードを奪い取ることができた。
そして、ID は特に秘密ではない情報だった。
記者会見に応じた 7pay 社（セブンイレブンの子会社として電子マネーの会社が作られた）の社長は、報道記者から「なぜ二段階認証を使っていないのか」と質問され、「二段階認証って何ですか？」と基礎知識がないことを衆目にさらした。
パスワード管理の話としてはどこから突っ込んだらよいのかわからないところだが、二段階認証の説明をしたい。
すでに使っている人は多そうだが、これが何を目的としているのかちゃんと認識している人は案外少ないように思う。
二段階認証は、「パスワードは第三者が簡単に盗めるものだ」という前提に立っている。
簡単に盗めるから、 ID とパスワードの組を知っているから本人、とは単純に認証できない。
一方で、現代では、多くの人が携帯電話を持っている。
そして、携帯電話には電話番号がある。この電話番号は、本人と強く結びついたものだ。
そこで、アカウントに対してあらかじめ「連絡手段」としての携帯電話番号を登録しておく。
連絡手段があればよいので、固定電話やメールアドレスが使われる場合もある。
ID とパスワードの組での認証に成功した際、これは「第一段階」を突破しただけで、ログインにはならない。
ここで、「二段階目」として、サーバーから連絡手段を通じて何らかの情報（通常は６桁程度の数字）が伝えられる。
携帯電話番号に対してショートメッセージを送信、というように、この情報は「本人だけが受け取れる」ことが期待される。
そして、受け取った本人が情報をサーバーに伝え、正しい場合にやっとログインが完了する。
この方法は、
・本人にだけ伝えられる情報を利用するため、正しく本人であると確かめられる。
・万が一パスワードが盗まれた場合、本人に通知が行くため、パスワードが盗まれたことを知ることができる。
という2つのメリットがある。
特に後者は重要だ。
先に書いたが、パスワードが漏れて明らかな被害にあえば、パスワードを再設定するなどの対策がとれる。
しかし、通常は「ただログインされて情報を見られただけ」では気づかない。
二段階認証では、認証中に本人に通知を行うことで、第三者によるパスワード盗用が明らかになる。
これにより「見えない被害」を事前に「見る」ことが可能となるだろう。
ただし、大体のシステムにおいて、二段階認証は「オプション」扱いにすぎない。
携帯電話などを持っておらず「設定のしようがない」ユーザーもいるためだ。
そして、オプションを使わなければ、従来どおり、 ID・パスワードの組だけで認証が行われる。
認証自体は問題なく行われるため、二段階認証を使えるシステムであっても、これが何のためにあるのか理解できずに設定していない、という人は多い。
Google や Amzon, Facebook 、Apple、Twitter …etc,etc. 多くの有名サイトが二段階認証に対応している。
認証していないシステムでも、「Google アカウントでログイン」などが使える場合は、Google の二段階認証を「借りる」ことができる。
設定していない人は導入を検討してみてほしい。
しかし、実はこの方法での二段階認証は、強度的に十分ではないことがすでに分かっている。
SMS の通信文は「他人に奪われる」可能性があるのだ。
SMS は、電話番号に対して発信され、スマートフォンなどのデバイスで受け取られる。
しかし、スマートフォンに電話番号が割り振られているわけではない。
割り振られているのは SIM に対してで、この SIM は付け替え可能だ。
そして、スマートフォンは PIN などでロックをかけられるが、SIM 自体がロックされるわけではない。
ほかのデバイスに差し込まれた SIM に対して送られたメッセージは、簡単にみられてしまう。
つまり、ちょっとスマホを置いて席を離れた間に、別の人が SIM を自分のスマホに差し替え、２段階認証を突破してしまう、ということも可能なのだ。
パスワードも知らないと二段階目まで進まないわけだが、ここまであなたの近くに潜り込める人であれば、ショルダーハッキングでパスワードはすでに知っている、と思ってよいだろう。
これは、物理的に近づかないといけない例だが、技術的には特に難しいことはない。
技術的な例でいえば、スマホアプリは、ユーザーの許可さえ受ければ SMS の内容を読みだすことができる。
悪意を持ったプログラムを内蔵した、ごく普通のゲームなどに見えるアプリが SMS の内容を盗み見て送信する…ということだってできるだろう。
もちろん、そういうアプリは操作の一部始終を見ていて、どこかにログインしようとしたときに ID/パスワードの組も送信しているわけだ。
また、国内の例ではないが、海外では携帯電話自体の通信プロトコルの脆弱性を突かれ、本来の電話番号の持ち主ではない端末に SMS を受け取らせてしまう、という攻撃も行われている。
SMS は決して安全ではない、ということがわかってもらえるだろうか？
メールアドレスに対する通知でも同じことがいえる。
むしろ、こちらの方が簡単に奪い取れるだろう。
固定電話は…本当の意味での「固定電話」なら、電話線に対して電話番号が割り振られている。
変更するには電話局内での設定が必要で、通信を盗むことは難しい。
しかし、今は「固定電話」といっても IP 電話であることが多く、これは後から機器に電話番号を割り振っている。
やはり過信は禁物だろう。
サーバーから本人に対して、「安全な通信経路が確保できる」というのが、この方式での二段階認証の前提だ。
安全な通信経路が確保できない場合、安全ではなくなる。
では、通信を行わないで、認証する瞬間にだけ使用可能な、本人だけが知れる情報で、サーバーに侵入されても情報が漏洩しない方法で、サーバーと秘密を共有すればいい。
そんなことできるの？ と思われるかもしれないが、ちゃんとそうした方法は考案されていて、一部の二段階認証では選択できるようになっている。
ワンタイムパスワード、と呼ばれるもので、仕組み自体は結構古い。
2006年…いまから13年も前には、すでにジャパンネット銀行が導入している。
先に「パスワードは時間によって変更したほうが良い」と示したが、それを究極まで突き詰めたものだ。
30～90秒で、自動的にパスワードが変更されてしまう。これなら、万が一パスワードが盗まれても問題ない。
パスワードが変わってしまうと、本人すらログインできなくなりそうだ。
しかし、本人だけが持っているデバイスに、変更されたパスワードが示され続ける。
だから、本人だけはログイン可能だ。
ここで重要なのが、パスワードを示すのに通信などは不要だ、という点だ。
サーバーとデバイスは、お互いに示し合わせることなく、次々とパスワードを変えていく。
しかし、それらは時刻を基にした一定の計算方法で示されるもので、デバイスとサーバーで一致している。
計算で示される…ということはランダムではないのだが、たとえ計算方法を知っていたとしても、「鍵」がなくては同じ計算が行えない。
そしてここが一番肝心なのだけど、計算のための「鍵」は、デバイスの中にしかない。サーバーにもない。
だから、万が一サーバーに侵入され、情報を盗まれてもパスワードを知ることはできない。
この鍵は、公開鍵暗号を応用したものだ。
公開鍵暗号は、「公開鍵」と「秘密鍵」のセットを使い、秘密鍵で暗号化した内容は公開鍵でしか元に戻せない。
だから、デバイスが秘密鍵を持ち、サーバーに公開鍵を預けておくと、デバイスが作り出した暗号が「確かに正しい」ことをサーバーは確認できる。
公開鍵は、秘密鍵を基にして計算で求めることができる。
しかし、公開鍵を基にして秘密鍵を割り出すことは事実上できない。
だから、サーバーに預けた公開鍵を盗まれたとしても、それを基に秘密鍵を求めてワンタイムパスワードを生成する、ということができない。
13年も前に導入されたジャパンネット銀行では、6桁の数値を表示できる専用デバイスを配布してワンタイムパスワードを実現している。
最近は、この方法を一般化した「時間ベースのワンタイムパスワード認証」が使われ始めている。
RFC 6238 で規格化されており、複数の会社が同じ動作を行うハードウェアやアプリを作成しているので、自分の好みに合ったものを使いやすい。
ただ、上にあげた、公開鍵暗号の応用によるシステムほどにはセキュリティが強くない。
上のシステムは、RSA 社が発明した特許品だから、金を払わずに同じ方式を使うことはできないのだ。
公開鍵ではなく、共有秘密鍵を使う。
ということは、万が一サーバーに侵入されれば、鍵は漏れてしまい、他者でも同じパスワードが生成できるようになる。
もし「疑いがある」時には、共有秘密鍵を変更することもできる。
通常は、サーバーにログインして操作し、ランダムな数値で更新させた秘密鍵を、手元のデバイス（スマホなど）で受け取る。
一般的には、QR コードなどで画面に表示する方法をとるようだ。
Google のアプリの場合、秘密共有鍵は「受け取り専用」なので、スマホを買い替えたりした場合は、サーバーに入り、鍵を更新して受け取る必要がある。
これに対し、同じワンタイムパスワード生成機能を持つ IIJ のアプリの場合、秘密共有鍵を QR コードとして表示する機能がある。
ということは、スマホの買い替え時などには、鍵を再発行することなく移行が可能だ。
これはとりもなおさず、第三者が秘密鍵を盗むのも簡単だ、という意味になる。
スマホ自体にちゃんとロックをかけておけば盗むための操作もできないはずだけど、どちらを使うかはお好みで。
ワンタイムパスワードの共通規格が普及しつつあり、２段階認証で使用できるサイトも増えている。
こうしたサイトが増えれば、パスワードを盗まれたとしても、簡単にログインされることはなく、被害は受けづらい。
しかし、現在のところ、こうした「安全な本人確認方法」に対応していないサイトは、まだまだ多い。
そうしたサイトでは、5年前の記事のパスワード管理方法は、依然として有効だ。
逆に、十分に安全なサイトで迄パスワード変更の手間をかける必要はない、ともいえる。
そうした安全なサイトが十分に増えて、パスワードなんて不便なものはなくなってくれればありがたいのだけど。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
先月１９日からだから、３週間ほど日記を書いてなかった。
その前に少し書いていたが、取引先を変えて仕事内容が大きく変わった。
それで忙しくて日記を書いてなかった。
より正確に言えば、「忙しくしていたので特に日記に書きたい面白いネタがなかった」だな。
忙しくても、ネタさえあれば日記を書く暇くらいは捻出する。
これだけだとあまりにも寂しいので、新しくやっている仕事について少し書いておこう。
具体的に何をやっているかは書かない。
別に企業秘密とか守秘義務とかではなくて、「宣伝になるから書いていいよ」と言われているのだけど、なんとなくまだ書く段階にないように思うから。
で、大きく分けて３つの仕事を同時にこなしている。
・WEB ブラウザで動作する、HTML + Javascript クライアントプログラム。素の Javascript だ。
WEB socket で得たリアルタイムデータを SVG でグラフィカルに表示し、同時に WEB Audio で音を出す。
作っていてなかなか楽しい。
・WEB ブラウザで連携動作する、Javascript + Vue.js クライアントプログラム。
まぁ、Vue を使おうが使うまいが、究極的には HTML + Javascript ではある。
しかし、複数ファイルに分けて書いたものをコンパイル・統合して配布ファイルを作る、というような、環境的には全く素の Javascript とは異なるものだ。
上に書いたプログラムとは完全別物だが、同じ大きなシステムの中の一部。
実は前任者が途中まで作り上げたプログラムを引き継いだので、まだ完全把握に至っていない。
しかし、Vue はなかなか興味深いプログラムスタイルだ。自分が一から作っていたら使わなかったと思うが、良い経験をさせてもらっている。
・上に書いた Vue プログラムは、もともとは PHP で書かれていたサーバープログラムを「移植」したもの。
PHP で複数ページにわたっていたプログラムを、Vue.js によって一つにまとめ、ページ遷移をすべてブラウザ側レンダリングで解決するようにしている。
となると、当然 DB とやり取りする部分をサーバー側に作り込む必要があるが、このプログラムは node.js で作成されている。
この部分も、Vue のプログラムを作っていた人が途中まで作っていたのを引き継いだ形。
以前仕事で node.js を使ったことはあって、その時の感想は「仕事で node.js を使うのはリスクが大きい」だった。
その頃は node.js はまだ新しいもので、環境が十分に整っていなかった。
本体やライブラリのバージョンアップのたびに、致命的な非互換が生じていた。
しかし、近頃の node.js は、当時と比べるとずっと安定しているようだ。
というわけで、３つの仕事ではあるが、全部 Javascript。
しかし、使ったことがある人ならわかると思うが、素の Javascript と、Vue などを使った Javascript と、node.js を使った Javascript は、環境的にかなり違う。
中途半端に Javascript という同じ部分を共有しているため、妙に混乱する。
（node.js の Javascript いじったのに、ブラウザリロードするだけで「動かない」と悩んでしまったり。
node.js はサーバーサイドなので、デーモンの再起動が必要）
まぁ、そんな感じのことやってます。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
自宅で仕事していると、会社帰りに同僚と飲むようなこともなく、外で飲む機会がほとんどない。
しかし、飲み会に誘われた。別々の個所から、２日連続で。
月曜日は、セガ時代の元同期が、僕を含めて３人集まった。
それに加えてもう一人年上の方がいたのだけど、その方のお勧めでお洒落なカフェレストランへ。
ワインリストとか出され、リエットとか岩牡蠣だとか、高級感あふれる食事。
こういうお洒落な店は慣れていないので、食事やワインなどお店を紹介してくれた方にお任せした。
とてもおいしかった。
火曜日は、先月まで仕事でご一緒していた方たちに誘われた。
ネットでつながり、ネットで仕事の連絡をしているため、５年も働いていたのにお会いしたことは数度しかない。
同じような立場で働いている人など、仕事上では密接にやり取りしていたりしたのに、初めてお会いした。
やきとん…豚の串焼きを中心とした居酒屋さん。
くだけた雰囲気で前日とは全然違うタイプのお店だが、これもまたおいしい。
直接担当してくださっていた方が、プログラマーではないのだけど、実は古いコンピューターが好きで CPU の命令セットなどもそれなりに詳しい、というのがちょっとした驚きだった。
（プログラマーではないので、個別 CPU の話に詳しいわけではないのだけど、CISC と RISC の違いとか、最近の CPU は複雑化しすぎて、投機的実行が元で脆弱性が生まれたりする、とか、結構突っ込んだ話が分かる人だった）
仕事での付き合い長かったのだから、もっと趣味の話をしていたら楽しかったかもしれない。
普段兼業主夫を標榜しているので、夕方出かけることはあまりない。
夕食作らないといけないし、皿洗わないといけないし。
なによりも、東京近郊まで出ると家から１時間半程度はかかってしまうんだよね。
往復３時間で、飲んでいる時間も３時間程度。
しかし、それがゆえにあまり出かけていなかったのが、久しぶりに出かけたらやっぱり楽しかったと、そういう話です。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
２日前に「Google Photos にバックアップする方法、ノートパソコンだとつらいなー」ってことを書いた。
で、その後調査していて、普通に Linux で動く Google Photos アップローダーを発見した。
なんでも、2018年5月…およそ一年前に Google Photos の API が公開されて、サードパーティ製のソフトも作れるようになったようだ。
で、使ってみたのだけど、満足するものではなかった。
画像を圧縮しないで、元画像のまま送り込むソフトだったのね。
他にも、EXIF がついてない画像…つけようがない動画なんかも、撮影日がアップロード日付になってしまうそうだ。
圧縮はソフトの問題かもしれない。
一応、ある程度送り込んだところで、Google Photos 側で「圧縮」処理してもらい、Google Drive 容量を開ける、ということもできる。
でも、日付は API に指定方法がないためどうしようもない、とのこと。
類似ソフトはほかにも発表されているようなのだけど、API がないのであれば他のソフトでも同じ問題は出るのだろう。
そんなわけで、やっぱり本命は Windows の仮想化か。
１つのソフトのために仮想マシンを用意して Windows インストールするとか、なんか間違っている気がするので、ほかの解決方法があるとありがたいのだけど。
余談。
いつものことだけど、余談のほうが長い。
冒頭にあげたアップロードツール、コマンドラインで動くのだけど、普通は GUIというか、X Window 必須です。
というのも、Google の認証が必要で、その部分は WEB ブラウザでないとできないから。
WEB ブラウザは、普通に考えると GUI がないと動かない。
流れとしては、
1) アップロードツール起動
2) 初回のみ、Google の認証が必要。URL が表示され、ブラウザでアクセスするように指示される。
3) ブラウザでアクセスし、Google の認証を通すと、その結果をツールが受け取って動作できる。
という仕組み。
一度認証を通せば、その認証情報はツールが保持するので以降は認証する必要はない。
僕は家庭内サーバーを完全 CUI で使っていて、Windows 上の Putty …端末ソフトで扱っている。
そこで、まず w3m をインストールしてみた。
文字だけで動作する WEB ブラウザだ。とにかく WEB ブラウザが動けば大丈夫そうだから。
ここで、実は操作を誤った。
文字だけになったら普段見ている画面と違うので、勘違いして別のリンクを押したのだ。
そうしたら reCAPTCHA 入力画面になった。
画像の中にゆがんだ文字が書かれていて、入力を求められるやつだな。
…テキストブラウザでは、画像が見えない。
どうしよう、と考えて、cacaview というソフトの存在を知る。
テキスト端末でもアスキーアートとして画像を表示してくれるソフトで、reCAPCHA の文字が読める程度には再現性もよい。
w3m はテキストブラウザとは言え、画像部分は外部ソフトに渡してみられるようになっている。
X Windows 環境で画像だけ別ソフトで開くことを想定しているのだけど、cacaview で開いたってもちろん構わない。
cacaview は CentOS なら caca-utils というパッケージを入れれば入る。
…で、さんざん苦労して認証を通して（やっぱ reCAPCHA 文字は読みにくく、何度も間違えた）、そのあとで「あ、これ違う画面だ」と気づいた。
本当に進みたかったルートではない。
本来進みたいルートに進んだら、あっさりと「Javascript が動かないので別のブラウザでお試しください」という画面になった。
w3m は Javascript が動かない。ダメだ。
しばらく考えて、サーバーに入っている nginx を使うことにした。
GooglePhotos のアップロードツールでは、localhost に対してアクセスを求められる。
そこで、nginx で適当な名前でサーバー公開して（もちろん家庭内だけ）、バックプロクシとして動作させて localhost にアクセスすればよい。
これで認証は通った。
最後に、GooglePhotos のアップロードツールに情報を渡すため、もう一度 localhost にリダイレクトされるのだけど、この部分で「localhost」ってことで、Windows にアクセスが行ってしまう。
まぁ、URL はわかったので、w3m でアクセスする。
これで認証が通った。
先に書いた通り、GooglePhotos アップロードツールは僕の求めていたものではなかったのだけど、この手順を踏めば、一切 X Window 環境なしに使える、本当のコマンドラインツールになる。
必要な人はお試しあれ。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |
新マシンに移行した。
旧マシンはしばらく使わないつもりで置いておく。
引き揚げ忘れたデータとかが眠っているかもしれないから。
でも、たぶん引き揚げ忘れたデータが本当にあったとしたら、それは忘れる程度のデータなので消えても構わないと思う。
実は、半年ほど前に旧マシンに Windows を再インストールしており、その際に「移行しやすいように」データ整理をしていたので、移行はスムーズにいった。
でも、若干の予想外もあった。
我が家では NAS に家族の写真・ビデオをたっぷりとため込んであって、この NAS は重要なので外付けハードディスクに定期バックアップもとっている。
しかし、それとは別に Google Photos にも写真を送ってバックアップしている。
「画質が落とされるのでバックアップにはならない」という人もいるのだけど、上に書いたように十分なバックアップは取った上の話だ。
Google のものは、万が一火事などで機材一切が滅失した際に、思い出写真として見られるのに十分なものがあればよい、という程度と考えている。
で、問題はこの Google に対するバックアップだ。
Google Drive を扱うツールは NAS のプラグインや Linux にもあるのだけど、Google Photos で「無制限」に写真を送るためのツールは Win / Mac 版しか用意されていない。
ここらへんで説明が必要な人も多いだろう。
Google Drive と Google Photos は、シームレスにつながるサービスだ。
Google Drive はネットワーク越しにデータを預かってくれるサービスで、Google Photos は写真を預かってくれるサービス。
でも、Photos の保存領域は、実は Drive のものだ。
ただし、Photos では「十分に小さな写真」は、Drive の容量として計上しないことになっている。
だから、今く使えば容量無制限で写真をバックアップできる。
ここで「十分に小さな」というのは、過去に何度か改定されてきている。
最初は、2048x2048画素以内、とされていた。実際にはバグがあって、ぎりぎりサイズはダメだったのだけど。
Google は、当時は Google Picasa というソフトを Windows 用に配布していて、このソフトからアップロードすると、自動的に 1600px まで縮小してアップロードしてくれた。
（当時は、Google Photos ではなく Picasa Web という名前だった）
のちに、Picasa は開発終了し、写真のバックアップだけを行う Google Photo Uploader が作られた。
そしてさらに、Google Drive バックアップと同期、というソフトに変わった。
同時に、保存できるサイズも大きくなってきている。
現在は「1600万画素、かつ 75MByte」までとなっている。4000x4000 なら、ちょうど 16000万画素なのでそのままアップロードできる。（75MByte の制限はあるのだけど）
ただ、この制限に適合するようにアップロードしてくれるソフト、「バックアップと同期」が、Windows / Mac 版しか作られていないのだ。
今までは、Windows 版のソフトを動かし、NAS をバックアップ元に指定して Google にアップロードさせていた。
今回もそれをやったら…これ、ノートにさせるような作業じゃないね？
今まではデスクトップマシンでイーサネット接続だったので、NAS から写真を取得して、リサイズして再圧縮して Google に送信、というタスクを動かしていても気にならなかった。
でも、WiFi 接続だとイーサより遅いし、WiFi の電波帯域は家族で共有しているので迷惑になりそう。
いや、イーサだって共有なのだけど、WiFi を使う機材とイーサを使う機材で棲み分けていた、という感じ。
（その WiFi はイーサにつながっているのだけど、一番通信量の大きい、僕のマシンと NAS の間、というのと、WiFi ステーションとネットワークルータの間、というのは、スイッチングハブによって切り分けられている）
ひとまず、ノートマシンにイーサケーブルつないで凌いでいるのだけど、どうにかしたい。
Linux サーバーはあるので、Linux から Google Photos にアップロードできればいいのだけど…と調べたのだけど、相変わらずそのためのソフトはない。
じゃぁ、Windows を仮想化してサーバーに入れるか。
幸い、メインマシンの Windows はライセンスを購入したもので、PC 付属の OEM ではない。
＃PC 付属の OEM 版は、別のマシンで使用することは禁じられている。
今まで使っていたメインマシンは、もともと Windows 7 マシンだったのだけど、8 にバージョンアップする際にライセンスを購入し、このライセンスは Windows 10 に無償バージョンアップされた。
Windows には「Hyper-v」という仮想化技術があるのだけど、これは実は Xen が開発したもの。
Xen は Linux で生まれた仮想化技術で、現在は KVM に引き継がれている、と考えて間違いない。
＃Xen 自体はまだあるのだけど、今から使うメリットはあまりない。
うちのサーバーは KVM が入れてあるので、この上に Windows を入れることは可能だ。
実は、Google Drive 同期とバックアップは、外部の NAS のデータを送信する際は、Windows がスリープして NAS との通信が切断するたびに一時停止する、という問題がある。
まぁ、問題というか仕様なのだけど、仮想化サーバーに入れておけばこの問題も解決する。
というわけで、Windows 仮想化が本命だなーと思いつつ、じつはまだサーバーの整備が終わっていないし、旧マシンもしばらく置いておきたいのでライセンスの関係もあってすぐには仮想化できない。
サーバー整備は、去年から少しづつやっているもの。
Xen サーバーの仮想マシンを KVM に移行したいのだけど、この意向を簡単に行うソフトが曲者で、一筋縄ではいかないとわかってきたところ。
「単純だけど本格運用には不満がある」仮想化マシンなら簡単に移行させてくれるのだけど、本格運用を目指した設定のマシンだと移行できないという…
まぁ、本格運用を目指した、というのは標準的でない設定をたくさん使っているという意味であり、仕方がないことでもあるのだけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |