日記帳だ! with Tux on Libserver

二度目の大改造!! 日記帳…か?を継承し、より柔軟でパワフルなBlogに変身しました。

RSSに対応しています。リンク・コメント・トラックバックは自由にしていただいてほぼ問題ありません。
RSS購読方法、僕のリンク・コメント・トラックバックについての考えを読むことをおすすめします。

<< 過去

マスターパスワードなんだけど

職場のパスワード管理に悩んでいたが、最近になってよい答えがでた気がする。

ここに行き着くまでは少し大変だったが。


職場のパスワード管理の最大の問題はパスワードの定期変更である。

Windowsログインなどで使うパスワードと、もう1つ他のシステムのパスワード、

これがけっこうな頻度で変更が必要で困っていたのである。


社内システムの多くはSSO(シングルサインオン)になっているので、

Windowsログインにつかうドメインパスワード1つでほとんど済むのだが、

ごく一部に独自のパスワードを持っているものがあり、これの変更頻度が一番高いという困った話。

しかも、最近何回かのパスワードと一致すると拒否されるという、これもまためんどくさい話である。

ドメインパスワードよりも苦しんできた経緯がある。


ドメインパスワード以外の管理は、社内の自分だけがアクセスできるネットワークストレージに、

ファイルを置き、このファイル自体にもパスワード暗号化をかけるという方法にすることにした。

社内のネットワークストレージなので、社内であれば他のPCからもアクセス出来る。

アクセス制御はかかっているし、気休め程度ではあるがファイル自体も暗号化されている。

メールさえ受信できればパスワードリセットはできるわけだし、ここら辺がよい落とし所でしょう。


困ったのがドメインパスワードである。

いわば社内においてはマスターパスワードと呼べるもの。失っても忘れても大変である。

こういうのは長くて覚えやすいものがよいとよく言われる。

しかし困ったことに定期変更が必要なので、長くて覚えやすいというのはなかなか難しい。


他のデバイスにパスワードを格納するということで、内線電話に格納しようかなとか模索したが、それも厳しい。

いろいろ考えた結果、固定のパスワードの前に8文字程度を付加することにした。

定期変更のたびに、パスワードの前に付加する8文字程度を変更することにして、その付加した文字をメモに残しておけばよいと。

紙のメモと内線電話のメモの2箇所に記録してある。

付加する文字列が少ないと、定期変更しても、変更前のパスワードから変更後のパスワードを類推される恐れがある。

固定の文字列が短いと、メモを見ただけでパスワードが割れてしまう。

この方法で定期変更も安心だし、従来のパスワードより長くなったのでその点でも安心である。


普段はWindows HelloでPIN認証にしているので、パスワードを入力することはない。

勤務先のポリシーでもWindows Helloは使えたんですね。

職場でWindows Helloの顔認証を使っている人がいたが、僕はPIN認証で。

覚える気はさらさらないパスワードを使っていると、Windows Helloのメリットは大きいよね。


ただ、その一方で、在宅勤務などで自宅からリモートアクセスする場合は、ログインIDとパスワードが必要である。

なので、職場で普段働いている限りにおいては、パスワードは忘れててもあまり問題はない。

極端なことを言えば、社内では定期更新後の最初のログインと、パスワード変更時の変更前パスワードの入力のときしか使わない。

しかし、ひとたび会社を出れば、必ず必要になるということで、どうにもめんどくさいのである。

(社外からのアクセスには通常のパスワードとは別の認証手段も併用する必要がある)


僕がここで働き始めたころは、社内のシステムいくつかで独立したパスワードを持ってて、今よりはるかに手を焼いたものだが、

残りはもう1つ、それもそう遠くないうちに他のシステムに置き換えられると言われている。(本当か疑われてるけど)

さすがに置き換え後はSSOになるんじゃないかなぁ。

SSO化が進み、Windows Helloも使えるので、社内のパスワードレスに近づいているのは確かである。

問題はマスターパスワードとも言うべき、ドメインパスワードの取扱なんだよね。

会社ではいろんな人が働いているし、コンピュータの使い方もいろいろ。万能な方法はなかなかない。

着実に改善されてますよ――とだけは言っておきますけど。


Author : Hidemaro
Date : 2020/01/10(Fri) 23:20
コンピュータ・インターネット | Comment | trackback (0)

スタック領域をどうするか

たいていの場合、プログラムを動作させるにはメモリ上のスタック領域を使う。

ローカル変数や関数呼び出しや割り込みしたときのプログラムカウンタやレジスタを待避させるのに使う。

当たり前の事ながら、このスタック領域のメモリを破壊すると、その後のプログラムの動作がおかしくなる。


ただ、マイコンの低レベルなプログラムではスタック領域を破壊するようなプログラムを書くこともある。

今回はスタック領域として使うメモリ領域を含めて、メモリ全体を特定の値で初期化するというものだったんだけど。

もちろん、スタック領域を壊すわけですから、関数の呼び出し元に戻ることは想定していない。

プログラムの初期化処理で行うわけですから、一方通行でよい。

しかし、今まさに使っている領域を破壊してしまうと、その時点で動作が狂ってしまうから問題である。


こういう場合、スタックを使用しないプログラムを作ればよく、じゃあアセンブラかと思ったんだけど、

うちの職場では、そういうプログラムも他のプログラムと同じようにCで記述されている。

当時のチームリーダーに聞いたら、できたとこ勝負らしい。

簡単なプログラムならスタックを使うまでもないわけで、Cでコンパイルしてもスタックを使わないプログラムが生成されることはある。

どうもそこを狙ってるらしい。そんなのアリかよと思うけど、ちゃんとコンパイル結果は確認しているのでご安心を。


ただ、今回の初期化処理はもうちょっと複雑なので、Cで書いてはスタックを使わずとはいかない。

じゃあどうしようかと考えた結果、このマイコンにはどうしても使い道のないRAMがあることに気づいた。

使い道がないというか、とある理由によりプログラムが通常動作になってからは使えないんだよね。

ただし、初期化処理の間に使うのはあまり問題がないので、すでに初期化処理の中で使用している領域だった。

初期化処理の前にスタックポインタを変更して、終わったところで本来のRAMへスタックポインタを戻すことにした。

こうすれば、RAMを初期化するプログラムでスタックを使ってしまっても問題はない。


ちなみにスタックポインタを変更する処理はアセンブラで書かれている。

ここでは数少ないアセンブラで書かれたプログラムである。

スタックポインタを変更してしまうと、基本的に元のプログラムには戻れないということで、

スタックポインタを変更して、指定されたプログラムへジャンプするというのがセットになっている。


今回、初期化処理中だけ使えるRAMがあったのは幸いだった。

メインRAMはとある都合により、全領域を初期化しなければ安心して使えないことが判明した。

「書きつぶすと初期化処理が長くなるから現実的とは言えないのでは」とは言われたが、

とある処理に紛れ込ませれば、処理時間が伸びないだろうと考えたわけである。実際にそうなった。

ただ、そうすると、なんとなく書いてスタックを使わないプログラムが生成されるわけはないし、

そこをなんとかするためにアセンブラで書くのも気が引ける。(類似するプログラムがアセンブラだったらやってたかもしれないけど)


もしも、スタック領域のRAMも含めて書きつぶさないといけないなら、2段階に分けてやってたかもね。

スタック領域として使っている部分を避けて書きつぶしてから、

スタック領域を使わない関数で残りを書きつぶして、スタックポインタを再設定するとか。

最初はそういうやり方も考えたのだが、めんどくさいしイマイチだなぁと思ったら、

そういえば、別のRAMにスタック置いても初期化処理なら許されるなと思ったのである。


こういうのはあんまり書かないプログラムだと思いますけどね。

このプログラムも1回作ってしまえば、同じものを同種のシステムでひたすら流用する予定だし。

出来てしまえば、初期化も何も考えなくて済むってことだし。


Author : Hidemaro
Date : 2020/01/07(Tue) 22:41
コンピュータ・インターネット | Comment | trackback (0)

FIDOじゃなかった

昨日、セキュリティキーの話を書いた。

セキュリティデバイスはそうそう売ってない

セキュリティキーの用途としてSSHのログインに使うというのがある。

家にssh鍵を忘れるという概念 (hiroqn's [Data.ByteString.Lazy.ByteString])

常に持ち歩いてないとこういうことも起きるよって話。


現在、世の中で販売されているセキュリティキーはFIDO U2F または FIDO2での使用を想定したものが多い。

FIDOの認証器というのは、本人確認(UV) や ユーザーの存在(UP)を確認する機能を持っている。

AndroidやWindowsの指紋認証をすると、指紋で本人確認と存在の確認が同時にできる。

一方でセキュリティキーとして販売されているものは、センサーに触れることで、誰かが存在していることは確認出来る。

かつてのFIDO U2F(Universal 2nd Factor、すなわち2要素認証) は、セキュリティキーは存在確認さえできればよかった。

本人確認はサービス側のパスワード認証でやるから、セキュリティキーを持った人がいることさえ確認出来ればよしだったと。

一方で、指紋認証機能の付いた端末と、タッチセンサーだけのセキュリティキーを同列に並べることはできないわけで、

FIDO2では、サービスがUVを要求すれば、セキュリティキーではPINコードを併用して本人確認しなければならないらしい。


なんて書いたはよいものの、実はSSHのログインに使うセキュリティキーの機能はこれではないのだ。

実はSSH秘密鍵の格納に使っているのは、PIVモードという、スマートカード互換の方式なのだという。

秘密鍵の格納先としてICカードを使うというのはだいぶ昔からある話で、マイナンバーカードもそうだよね。

マイナンバーカードはPIV互換ではないのだが、世界的には歴史のあるシステムのようだ。

よくよく調べてみると、現在普及しているセキュリティキーでは Yubico社 の YubiKey のFIDO専用ではないものを使うのが前提らしい。


YubiKeyが搭載している機能 (ソフト技研)

FIDO U2F & FIDO2 は最初に書いた機能である。この機能だけのセキュリティキーを売っている会社は多い。

Yubico社はこの機能に限定したセキュリティキーを売っていて、定価ベースで3割安くなっている。

チャレンジレスポンスもこれに類する方式だが、YubiKey独自方式かな。

OATH-TOTPはGoogle認証システムと同じやつですね。(cf. ワンタイムパスワードとの2要素認証)

Smart Card, Open PGPはどちらも秘密鍵を格納する機能という点では同じ。SSH秘密鍵は通常これを使う。

Yubico OTPは、YubiKeyでもっとも歴史ある機能のようだ。

キーボード互換のデバイスとして認識され、センサーをタッチすると44桁のカウントベースのワンタイムパスワードが入力される。

非常に長いが自動入力なので手間がかからないということで、安全性と利便性が両立できると。

パスワードの後ろにYubico OTPを付けて送って、受け取った側で分解して(Yubico OTPは固定長)検証すればよいので、早期に普及したらしい。

OATH-HOTPとSymantec VIPも同じくワンタイムパスワードのキーボード入力、安全な静的パスワードは固定文字列がキーボード入力されるというもの。


これを見て思ったのは、YubiKeyってキーボード互換・PIV互換という既存のデバイスになる機能が特徴なのかなと。

今でこそFIDO U2FまたはFIDO2というところで、セキュリティキーの標準的な利用法が確立されたけど、

そうやって普及するまではキーボード互換でワンタイムパスワードの自動入力をしますとか、

そういうところから入らざるを得なかったのかなと。そうして切り開いてきたから今のFIDOがあるんだろうけど。

FIDOだけでよいというのなら、YubiKeyはオーバースペックでやや高価ということになる。


YubiKeyでのSSH認証の使い方を見ていると、PCで生成した秘密鍵を書き込む方式が一般的のようだ。

一回書き込んだ秘密鍵はキーの外に出せないことは保証されているが、同じ秘密鍵持ったキーを複数作ることはできるかもしれない。

マイナンバーカードと同じようにPINコードで認証して秘密鍵を呼び出すことになる。

メリットは秘密鍵を安全に運搬できること。これが全てということになろうかと思う。


FIDO用の秘密鍵をSSHの認証に使う方法ってあるのかなと調べたが、

今のところは Gravitational Teleport というWebで認証してSSHを利用するシステムでは使えるとか。

SSHそのものがFIDOによる認証に対応しているというより、中継サーバーが対応してるよって感じみたいね。

理屈上はFIDO認証器(セキュリティキーまたはAndroid・Windows)の内部で持っている秘密鍵を利用して、

それに対応する公開鍵をSSHサーバーに指定しておけば認証出来るんじゃないかという気はするんだが、

まだ、そのためのソフトウェアができていないというのが実情なのかなと。

PIV互換方式ならば、既存のソフトウェアで対応できたから、現状はそれでやってますよと。


理解してる人には当たり前かもしれないけど、ちょっとダマされた気になってしまいましたね。

言われて見れば、SSHでセキュリティキーを使うという記事で使ってるのは、どれもこれもYubiKeyだった。

一般のFIDOで使ってるセキュリティキーは 飛天(Feitian) とか他のメーカーも使用例があるんだけど。

とはいえ、複数メーカーから選べて、比較的安価なセキュリティキーを広く使いたいというニーズはあるはずで、

そのうち打開されるんじゃないかという気はしますけどね。

それができるようになると、Windows Helloで指紋認証して、SSHにログインというのも夢ではないかも知れない。


Author : Hidemaro
Date : 2019/12/18(Wed) 23:49
コンピュータ・インターネット | Comment | trackback (0)

セキュリティデバイスはそうそう売ってない

ヨドバシカメラで指紋認証器を買ってきたという話を書いたが(cf. 銀行アプリの指紋認証は使えるか)、

実は店頭に置いてあったわけではない。

入力デバイスなのかなぁとか探したんだけどないんだよね。

通販には置いてあって、しかもよく見てみると店頭受取で「30分以内にご用意いたします」となっている。

どうも店頭には並べていないが、店に在庫は置いてあるらしい。ヨドバシはそんな在庫の持ち方してるのか。

もっとも安いものだと1000円ほどである。これでも Windows Hello で使う分には全く問題ない。


Windows Hello はパスワードを使わない認証方法として 顔・指紋・PIN認証を提供している。

PIN認証ってパスワード認証じゃないのかと言われたら、知識による認証という点では確かにそうなのだが、

Microsoftアカウントのパスワードではないというところがポイントらしい。

Microsoftアカウントのパスワードが流出すると他のデバイスでもログインされかねないが、

PINコードはPINコードがセットされたPCとセットで意味を成すので、物と知識による2要素認証であるわけだ。

もっとも、このPCではローカルアカウントなので、ログインパスワードとMicrosoftアカウントのパスワードは無関係なのだが。


とはいえ、Windows Hello を使うならば、PINコードの登録は必須である。

指紋や顔を登録するならば、それと同時にPINコードも登録しなければならないのだ。

Windows Hello のPINコードは桁数も自由だし、数字に限らないので、ローカルアカウントのパスワードと同じに設定した。

指紋認証が使えないときの代替手段ですね。まぁパスワードも代替手段ではあるんだけど。

指紋認証を使うメリットはやや複雑なPINコードにしても不便でないことだと思うので、

PINコードといえば4桁の暗証番号だろうというところにとらわれない方がよいかもしれない。

実際、AndroidのPINコードは指紋認証前提に長くしてある。


今のところ、Windows Hello の用途はWindowsのログインと、Google Chromeに保存しているパスワード表示のときぐらい。

Chromeに保存されてるパスワードを他の用途に使うときにはパスワードを表示する必要があるが、

このときにWindowsの認証が要求されるので、指紋をタッチすればOKと。

複数人で使うPCだと、指紋でユーザーを判別してログインできるとか、そういうメリットもあるんだが。

今後、WindowsでもFIDOを使った生体認証が普及すれば役立つ機会も増えそうなんだが。


ところで最初の話に戻るのだが、指紋認証器とともに店に並んでるかなと期待したのがセキュリティキーである。

具体的に購入したかったわけではないのだが、セキュリティデバイスというくくりでは同じかなと。

FIDOに準拠した認証セキリティデバイス (飛天ジャパン)

これ、何なのかという話だけど、暗号鍵を内蔵したデバイスである。秘密鍵は外に取り出せないので複製できない。

例えば、Googleの2段階認証にセキュリティキーを設定すると、PCでもスマートフォンでも同じキーが接続された機器しかログインできない。

職場のPCでも、持ち歩いてるスマートフォンでも、家のPCでも、同じセキュリティキーを接続しなければならない。

なので、家の鍵のように持ち歩くことが想定されていて、それでキーホルダー用の穴があるんですね。

スマートフォンへの接続はNFCを使用することも想定されている。(USB接続でもよい)

こちらは店頭にないどころか、ヨドバシの通販にもない。Amazonなら普通に買えるみたいだけど。


この辺の品揃えを見て思うのは、セキュリティデバイスという考え方がまだ一般には普及していないということだよね。

指紋認証については、ノートPCでビルトインのものは多いが、後付けするのはあまり一般的ではないと。

ヨドバシで見る前に、秋葉原界隈の店を渡り歩いて調べてたときもそうで、だからPC自作する人もあまり興味はないんだろうと。

デスクトップPCだとビルトインはあまりないので、一般のご家庭でも使いたいというニーズはありそうだが。


セキュリティキーは、用途からすれば、気軽に買って使い始められてもよさそうだが、実際はそうなっていない。

まぁAmazonで買えば1個から即納なんで、それでよいといえばそうなのだが。

セキュリティキーを使うのは会社から言われているか、物好きかどっちかというところではないか。

インターネット時代に物理的なキーを使うというところに違和感を覚える人も多いんだろうと思う。

正直、僕もそう思っているのだが、パスワード認証だけでは厳しい実情があって、

そこに対抗するには物を使った認証が必要で、複数の機器で唯一の物を共用することを考えると、ああならざるを得ないのかなと。

まだ発展途上かなと思わなくもないが、安く気軽に持てないとなかなか広くは普及しないのかなと。

在宅勤務などで会社のリモートアクセスを使う時とかに使えると便利そうだと思ったが。その場合は会社が買うか。


Author : Hidemaro
Date : 2019/12/17(Tue) 23:54
コンピュータ・インターネット | Comment | trackback (0)

自分のサーバーに画像を置きたかった

今日は有給休暇取得推奨日だったので、家でサーバーを触ったりしていた。

ちなみに今日が推奨日なのは、12月に祝日がないから。年末年始の休日はあるんですけどね。


クラウド上に置くにははばかられるが、インターネットから自分だけ見られるようにしたい画像ファイルがあった。

もちろん適切にアクセス権を設定すれば、自分だけが見られる状態には出来るが、管理者にも読めないわけではない。

自分のサーバーに置けば、おそらく自分以外の人がファイルを触ることはできないし、

SSL証明書認証で自分だけが見られる状態を保証することもできる。

クライアント証明書で通す

これに加えてSSLRequireディレクティブで証明書のCNの条件も加えた。


サーバーに置いて、それを自分だけでHTTPSでアクセス出来るようにすること自体は難しいことではないが、

スライドショーのようにして読めるようにしないと、とても使えたものではない。

どうしたもんかなぁと思っていたら、ちゃんとそういうJavaScriptのライブラリがあるんですね。

jQuery lightgallery

他にもいろいろあるんだけど、もっとも目的にかなうのはこれだった。

サムネイルに画像ファイルへのリンクを付けたものを列挙しておいたものにライブラリを付けると、

サムネイルをクリックすると、画像が拡大されて、スライドショーが表示されるように変換されるようだ。

これを使えば、サムネイルとリンクだけのシンプルな記述で、十分に機能的なページができた。

自分しか使わないのだし、多少味気なくても機能的なら問題ないでしょう。


もう1つ気になったのが画像ファイルの容量のこと。

最初はサーバーのストレージ容量の心配をしたが、200GBもあるから余裕だった。

ただ、画像ファイルの容量削減自体は読み込みスピード向上に効果があることでもある。

写真の場合はJPEGが標準的な形式だが、より圧縮率の高い方式もあったよなぁ。

そこで調べたところ WebP というのが比較的普及しているようだ。


WebPはGoogleが開発している動画コーデックVP8を静止画に適用して作られた形式である。

Googleが普及に取り組んでおり、Google Chromeは早期に対応、Mozilla Thunderbird、Microsoft Edgeも対応した。

Internet Explorerは対応してないが、Edgeを使えばOKと考えると、Windowsであればほぼ問題ないでしょう。

もちろん、ほとんどのユーザーがChromeを使っているAndroidも問題なし。

ただ、Appleがさっぱりで Safari は未だ非対応ということで、ここがWebPの課題である。

一方でSafariは JPEG 2000 に対応してるんだよね。ただ、JPEG 2000は他のブラウザがさっぱりダメという。

今回の用途はAndroidかWindowsで、どちらもChromeでの表示を想定しているので、WebPで全く問題ないだろう。


変換ツールはGoogle自身も提供しているようだ。(cf. Getting Started (WebP))

同時に巨大な画像の縮小などの処理もやりたかったので、いろいろ探したら XnConvert に行き着いた。

Quality Factorは70にして変換したが、元のJPEGの1/4以下になった。

もっとも、元のJPEGの出力条件が最適だったわけでもないし、なにより大きい画像ファイルはリサイズしている。

Googleの資料によれば、同じ品質のJPEG画像に比べれば25~34%軽くなると書かれている。

本来の実力はそんなもので、JPEGでも適切に生成すれば1/3ぐらいの容量にはなったんだろう。

同時にサムネイルも作成した。こちらはサイズも小さいが画質も問わないのでQuality Factorは30で。さすがに汚い。

あとは、普通にサーバーに置くだけだが、/etc/mime.typesにWebPがないので追加する。

image/webp                                      webp

WebP画像について、Chrome・Firefox・Edgeでの表示においては全く問題ない。

Windowsでは、サムネイルは表示されるが関連付けはChromeになってた。

標準のフォトアプリでは表示できないが、ペイントは読み込むので全く非対応でもないらしい。作成は出来ないが。

画像編集ソフトでの対応状況は悪く、最初からWebPで出力しようというのは難しい。

SafariとInternet ExplorerがWebP非対応であることもあって、WebPへ一本化というのはまだ現実的ではなく、

一旦、JPEGで作成して、これをWebPに変換するという使い方にならざるを得ないのかなと。

あと、ユーザーにもWebPには戸惑いもあったようだ。ダウンロードしてもそれを使えるソフトが少ないからだろう。
(cf. グーグルの画像形式「WebP」を試行するFacebook--ユーザーからは不満の声も (CNET))

Safariが最後の砦なのかもしれないと思ってたが、そう簡単な話でもないのかもしれない。


こうしてサムネイルと画像へのリンクを貼ったわけだが、一部のサムネイルの読み込みに失敗する。

なんでだろうと調べたら503エラーを返しているようだ。

503エラーというと、MaxClientsで設定した値以上にアクセスがあったときに出るようだが、そんなことはないだろう。

原因は mod_limitipconnで同一IPアドレスからの接続数を制限していたからだった。

もともと MaxConnPerIP には5を指定していた。同一IPからの接続数が5を超えたら503エラーを返すと。

どうも大量にサムネイルがあると、ブラウザは大量のコネクションを張って、5コネクションを超過したようだ。

この数を緩和すると問題は解決したのだが、なんでそんな行儀の悪いことをしてるのか……


あと、このときに Lazy Load という、これもまたJavaScriptのライブラリを導入した。

一気にサムネイルを読み込むのが悪いんだろうと思って導入したのだが、

数百個が数十個に減っても、MaxConnPerIPの規制値にかかってしまうので、結局、効果はなかったんだが。

とはいえ、画面の外にある画像のロードは後回しにして、ページ表示が完了するので、それ自体は好ましいことではある。

こういうのが簡易に導入できるんだから便利な話ですよ。


Author : Hidemaro
Date : 2019/12/16(Mon) 23:52
コンピュータ・インターネット | Comment | trackback (0)

電池をとるか、指紋認証をとるか

スマートフォンの買い換えを考えている。

今使っているAndroid One S3は、ストレージ容量不足に対応して購入したものだった。

USB PDで急速充電OKのはず

安かったのはよかったが、当初から性能面では問題だろうと思っていた。

ストレージ容量の問題が解決したことで、ゲームで遊ぶ時間が増えてなおさら問題になってきた。

もともとつなぎとして購入したような面はあって、1年経たずに買い換えること自体は妥当だろうと。


それでY!mobileのWebサイトを見ていると、秋から冬にかけて新発売の端末リストが出ていた。

2019 AUTUMN & WINTER NEW COLLECTION (Y!mobile)

SONY Xperia 8、ZTE Libero S10、Android One S6(京セラ)、Android One S7(SHARP)が並んでいる。

あと、すでに8月から販売されている HUAWEI P30 lite、この5つがY!mobileの商流で買える端末かなと。


搭載されているチップからCPU・GPU性能はだいたい想定できて、

Xperia 8 と Android One S7 は同じSnapdragon 630、Libero S10はSnapdragon 450なのでそれより性能は劣る。

Android One S6はMediaTek Helio P35で、Snapdragon 630と同じぐらいだが少しよいかもしれない。

P30 liteはこれらのチップを積んだ端末よりはるかに性能が高いようである。

とはいえ、現在使っているAndroid One S3と比べると、Libero S10以外は大幅な性能向上であろう。


それ以外の特徴を見てみると、似たり寄ったりだが、少しずつ違う。

まず、NFC/Felica対応はXperia 8、Android One S6、Android One S7 の日本メーカーの3つが対応。

ちなみに今のAndroid One S3はNFC/Felica非対応である。

次、電池容量、ほとんどが3000mAh前後だが、Android One S7は4000mAhという大容量の電池を積んでいる。

「1週間の電池持ち」と書かれているが、さすがに1週間持つのはほぼ待ち受けに近い場合だが、

電池容量の多さと、IGZO液晶を搭載して画面の消費電力を抑えたということで、電池持ちはよさそう。

この辺、SHARPらしいなと思う。Android One 507SHのときも電池はセールスポイントだったし。

指紋認証、いまどきは標準搭載なのかと思って見ていたら、Android One S7 だけ付いていない。

指紋読み取り部は、Xperiaは側面、他は背面のようだ。背面が多数派なのか。

ストレージ容量は Xperia 8 と P30 liteが64GB、他は32GB、いずれもmicroSD対応。

今までの実績だと32GBあれば足りないことはないかな。microSDが併用できるのは前提だけど。


ここまで見てきて思ったのは、やはり電池という面でAndroid One S7はいいなと。

サイズ感もこの中では長手方向の長さではもっとも小さく、その点でも僕の希望とマッチしている。

ただ、唯一気になるのが指紋認証に対応していないこと。

SHARPのWebサイトを調べてみると、Y!mobile向け以外では AQUOS sense3 として発売する製品に相当するようだ。

ただ、スペック面では差があり、AQUOS sense3は外向きのカメラが2種類付いているのに対して、

Android One S7は1つ、この点については楽天モバイル専売というAQUOS sense3 lite と同じ特徴である。

ストレージ容量が64GBに対して32GB、そして指紋認証は他がありでAndroid One S7は なし となっている。

楽天モバイル専売のAQUOS sense3 liteは、ここは64GBで指紋認証ありなので、それとも違うという。


指紋認証いるか? というところは悩み所である。画面ロックだけなら別になくてもとは思う。

ただ、HUAWEI MediaPad M5に指紋認証がついていて、確かに便利ではあるんだよね。

最近、Googleパスワードマネージャーでパスワードの管理をさせるようになったわけだが、

Chrome以外でパスワードを使うときはパスワードのコピペが必要で、

そのためには、Androidでは端末の画面ロック相当の認証が必要になるが、指紋だと煩わしくない。

あと、FIDO というパスワードレスログインがこれから普及しようとしているが、

スマートフォン+生体情報というのがもっとも普及しそうな方式で、そこで指紋が使えるか使えないかは大きな差かなと。

FIDOってだけなら、スマートフォン+PINコード とか セキュリティキー というのもあるんですけどね。


まぁY!mobileの商流にこだわることはなくて、他の方法で買ってもいいんですよね。

Y!mobileから買う方が有利なことはあるが、SIMフリーの端末を購入するのもそんなに不利なわけではない。

AQUOS sense3はAndroid Oneとそう変わらなくて、発売後2年間で最大2回のOSアップデートをすると言っている。

いろいろ調べた限りではAndroid Oneと同じような感じで、少しSHARP独自アプリが入ってる程度なのかなと。

Android Oneで慣れているので、指紋認証付きAndroid One S7だという考えもある。(価格も大きく変わらんだろう)


もう1つ選択肢に入りうると思っているのが HUAWEI P30 lite である。

HUAWEIはMediaPad M5で使ってるから、いろいろわかってきたが、基本的にはいいと思う。

ただ、設定でHUAWEI独自色が強いのが気になったり、すこし性に合わないところもある。

画面上部に設けられたノッチも気になってしまう。これは慣れかもしれない。

あと、FIDOについては、なぜか みずほ銀行 のアプリではHUAWEIダメみたいね。これはようわからん


Y!mobile以外から購入する場合、基本的にはUSIMカードを差し替えれば終わりなのだが、

NFC/Felica対応の端末の場合、今使っているn111というタイプのSIMはNFC用のIDが入っていない。

ご丁寧にもAndroid One S3への買い換えのときに、n101(NFC対応)からn111へ交換されちゃったのね。

HUAWEI P30 liteのように、NFC非対応の端末なら、それはそれで関係ないことである。

とはいえ、NFCを使う時だけの問題で、NFCを使わないならn111のままでもいいし、後で交換してもかまわない。

SIM交換については、Y!mobile店舗で「機種変更」を申し出れば、3000円(本体)の手数料でやってくれるそう。

これは店頭でY!mobile取扱端末を購入する場合と同じ手数料である。(オンラインショップではかからなくなった)

そんなところで総合的に判断するのかなと。今までの実績だとY!mobileでAQUOS sense3の取扱はないでしょうし。


Author : Hidemaro
Date : 2019/12/09(Mon) 23:22
コンピュータ・インターネット | Comment | trackback (0)

暗号化されているかいないか

職場で使っているPCは基本的にはレンタル品だが、一部には自社所有のものもある。

といっても、特殊なスペックのコンピュータか、レンタル品を現品で購入したものかどちらかなんだけど。

Windows 7 PCを買ってWindows 10を入れる

こういうこともやってるんですね。


上司が部署のセキュリティについてのチェックリストを確認していたときに、

レンタル品ではないPCに「部署管理品」というシールが必要なのではないかという指摘をしてきた。

これ、以前も気になって調べたのだが、実はこのシールの対象はノートPCだけなのである。

しかも、レンタル品ではないノートPCの全てにこのシールが必要なわけではないのだという。

実はこのシールにはある目的があったのである。


それがストレージの暗号化である。

どうも会社のルールでは、ノートPCは原則としてHDDなどのストレージを暗号化しなければならない。

これは社外に持ち出すストレージには原則として暗号化が求められていることに対応している。

今ではレンタルPCはストレージの暗号化設定がされた状態で納入されていて、

起動時にパスワードを入力することを除いて、暗号化を意識することはない。

ただ、過渡期には後付けで暗号化を導入する必要があったようで、その識別用のシールがあった。

暗号化設定がされたものは対策済みシールを貼り、暗号化対策しないことを認めたものは「部署管理品」シールを貼っていたようだ。


それも今は昔、レンタル以外でノートPCを調達することはほとんどないだろう。

古い開発環境を保持する目的で暗号化がなされていないノートPCがある可能性はあるけど、

暗号化導入後のレンタルPCを買い取ったとすれば、それもそれで問題はない。

再確認はするべきだけど、そもそも「部署管理品」シールの対象になるPCは少ないだろうな。


ただ、この背景を知ったときに、あれ? と思ったことがあった。

それがデスクトップPCはストレージの暗号化をしていないということ。

ノートPCであれば(実際に持ち出すかはともかく)、社外に持ち出される可能性を想定して原則暗号化と言っている。

暗号化されていないPCには識別用に「部署管理品」のシールを貼りなさいと言っている。

これがデスクトップPCになれば、社外に持ち出されない想定なので、暗号化も原則やらないし、識別シールも貼らない。

でも、実際には製品評価の目的で社外にデスクトップPCを持ち出すこともあるんだよね。


今まで、社外にデスクトップPCを持ち出す案件に関わったことはあるが、暗号化が求められたことはない。

原則暗号化というけど、技術的に暗号化できないとかいうなら、搭載されているデータを精査するなどして持ち出すことが認められることもある。

「部署管理品」シールが貼られていても、必ずしも社外持ち出し禁止ではないということはQ&Aにも記載されていた。

実際、製品評価のために持ち出すPCにセンシティブなデータはほとんど含まれていないと思われる。

ノートPCに比べれば置き忘れのリスクは低い。(輸送手段もチャーターのトラック便が多い)

信頼がおけると考えている試験場に設置して使われるので、他人が触れるリスクは低い。

ここら辺を総合的に考慮すれば、暗号化せずともOKという判断は成り立つが、そこまで熟慮されたかは疑問もある。


それで気になって、先日、レンタルの現品を購入したデスクトップPCのBIOSを確認してみた。

そうしたら、BIOSの設定項目に HDD Password という項目があるんですね。

HDDを抜き取っても、パスワードがわからない限りは読み出せないということで、

ストレージに求められる暗号化の要件を満たせているはずである。

だから、この設定をしておけば、デスクトップPCも大手を振って社外持ち出しができるということである。


一方でストレージの暗号化の実効性ってどんなもんよという話もある。

メーカーはストレージを他の機器に付け替えても使えないので安全だと言っている。

ただ、どういう技術で暗号化をしているかという情報はあまり明らかではなく、

あまり出来の良くないものでは、特殊なアクセスを行えばパスワードが読み出せてしまうなんて話も。

そもそもパスワードを総当たり攻撃されたらどうなんだとか、気になるところは多い。

気休め程度の機能と割切ってればいいんだけど、どうなんでしょうね。


Author : Hidemaro
Date : 2019/12/06(Fri) 23:13
コンピュータ・インターネット | Comment | trackback (0)

マイナーな認証方式ではある

IMAP, SMTPサーバーの認証方式として、SSL/TLS証明書というのはあまり一般的な方法ではない。

それだけに対応しているソフトも限られる。

WindowsではMozilla Thunderbirdはいけるが、他はどうなんだろうか。

Androidでは僕が以前から使っていた K-9 Mail はいけるが、他に使えるのが見あたらない。

しかも K-9 MailはSMTPの証明書認証に対応しているようだが、うちのPostfixの設定だと証明書認証と認識してくれない。

Thunderbirdは証明書認証で動いているので、根本的な問題ではないと思うのだが。

(現状はPostfix専用のパスワードを使った認証を併用している)


Thunderbirdの設定を見てみると、IMAPでは、次の認証方式に対応している。

  • 通常のパスワード認証
  • 暗号化されたパスワード認証
  • Kerberos/GSSAPI
  • NTLM
  • TLS証明書
  • OAuth2

ほとんどは「通常のパスワード認証」でしょうね。

「暗号化されたパスワード認証」はSSL/TLS普及前に使ってたもので、今はもう使う人はほとんどいないだろう。

多くのメールソフトはここで終わり、この先に4つも連なってるのはThunderbirdぐらいしかないかな。

TLS証明書はこれまでも紹介してきた通り。(cf. クライアント証明書で通す, パスワードを没収されたので)


問題は残り3つである。

Kerberos/GSSAPI と NTLM はどちらもシングルサインオンの方式である。

認証情報を持った端末であれば、何のパスワードも聞かれることなく認証が完了するということ。

KerberosはMicrosoftのActive Directoryで標準的に使われている方式で、

勤務先の各種サービス(勤怠簿とか)のシングルサインオンもこれなのかなぁと思ったがどうなんだろ。

MicrosoftのWindows用に使われていることが多そうだが、これ自体はオープンな方式で、Active Directory以外でも使われてるそうだ。

NTLMはMicrosoftが以前使っていた方式で、今は推奨されないらしい。

この辺は、Thunderbirdを企業用のメールクライアントとして使うことを想定したものなのかな。


最後に書かれているOAuth2だが、これは実は対応しているメールクライアントは多そう。

というのもGmailを使うなら、この方式に対応している必要があるから。(アプリパスワードを使う場合は別)

ただ、Gmail専用になっていて、一般的なIMAPの設定に使えないことも多いかも知れない。

別にGoogle専用の方式ではなく、ちゃんと標準化された方式なんですけどね。


OAuthというとTwitter使ってる人にはなじみ深いけど、他のアプリやWebサービスと連携させるとき、

「○○があなたのアカウントを利用することを許可しますか」と、一定の権限を許可するか聞かれるが、

あれがOAuthで、ここで許可すると一定の範囲でアカウントを操作することが出来る。

許可したアプリは設定から随時取り消すことが出来る。一方で取り消さない限りはパスワード変更などしても継続して使える。

OAuthで許可を得たアプリは、パスワード情報を握っておらず、許可した範囲の操作だけできるということ。

それでOAuth2では、これがIMAP・SMTPなどにも適用できるようになったので、Googleは使っているということ。

OAuth2を使うと、初回にGoogleの認証をしてGmailの許可を出せば、以後はその権限を使ってアクセスするのでパスワードは関係ない。


SSL/TLS証明書というのも、マニアックな認証方法の1つだってことですよ。

いずれも共通して言えるのはパスワードレスであるということ。

パスワードレス化というところを考えるとぜひ使いたい方式である。

Kerberos/GSSAPIは組織内で決められたアプリを使うようなやり方になるんだろうと思うけど、

OAuth と SSL/TLS証明書 は広く使われそうな予感がする。

汎用のメールクライアントを使うのが時代遅れだって? まぁそんな気もしなくはないがThunderbird使いやすいし。


Author : Hidemaro
Date : 2019/12/01(Sun) 23:30
コンピュータ・インターネット | Comment | trackback (0)

ワンタイムパスワードとの2要素認証

このサーバーのBlogやメールサーバーへのログインをSSLクライアント証明書による認証に切り替えた話を書いた。

パスワードを没収されたので

証明書は自動発行すれば良い

このとき今後の課題についてこんなことを書いた。

あと類似するところでSSHのログイン用の秘密鍵の管理も課題がある。

ローカルに配置するとその端末でしかログインできない、

かといってオンラインストレージにおくと流出の懸念なしとは言えない。

というわけで、SSHのログイン方法の見直しを行っていた。


オンラインストレージからの流出は本当に恐れるべきことなのかというのはある。

とはいえ、鍵データだけに依存する状況もよくない。

一応、鍵データを紛失したときのワークアラウンドとしては、VPSのコントロールパネルから操作するという方法がある。

これはsudoが効かなくなったときのワークアラウンドでもある。(コンソールではrootへのログインもできるので)

ただ、SSHのログインに使える「物」が、鍵データ以外にあってもよいと思う。


いろいろ調べて、いろいろ考えた結果、

鍵データ または Google認証システムのワンタイムパスワード+Linuxのパスワードというところに落ち着いた。

まず、SSHの鍵認証は単独でも十分に安全性が高いといってよいだろう。利便性も高い。

ただし、鍵データの管理に十分注意が必要なので、本来は鍵データはむやみやたらに持ち出さないだろうと。

鍵データを持っていない場合、あるいは紛失した場合の代替手段としては「物」と「知識」による2要素認証だろうと。

知識はLinux自体のパスワードでよいと思うが、物を何にするかは少し迷った。


住信SBIネット銀行のログインロック機能のように、端末操作を行った後、しばらく認証が通る方法も考えた。

ただ、SSHをどんなときに使うかと考えてみると、他のサービスが正しく動作していないときに使うことも多い。

そうなるとSSH単独で他のサービスに依存せずに動く方式がよいだろうと。

そこでGoogle認証システムである。

Googleとは付いているけど、Googleが開発したってだけで、Googleのサービスに依存して動くものではない。

Google認証システムはワンタイムパスワードを生成するアプリで、このアプリの入った端末はオフラインでもよい。

オープンソースのワンタイムパスワードのシステムとして普及したものである。


そこら辺にいくらでも導入方法は書いてあるが、ここにも書いておく。

SSHでGoogle認証システムを使う場合は、PAM認証のプラグインとして導入する。

yumでインストール出来なかったので、ソースコードでダウンロードしてきてインストールする。

google/google-authenticator-libpam (GitHub)

書いてある通りにビルドすると /usr/local/lib/security/ にインストールされるので、/etc/pam.d/sshdの先頭に次の一行を追加する。

auth       requisite    /usr/local/lib/security/pam_google_authenticator.so

これにより、Google認証システムによるワンタイムパスワード認証が通れば、従来のパスワード認証に進むということになる。

requisite を require にすると、失敗してもそれを隠して次に進む。

どちらがよいかは場合によるだろうが、今回はワンタイムパスワードでだめでしたとすぐわかる方がよいだろうと。


これでsshdのPAM認証がワンタイムパスワード+Linuxのパスワード認証 になったので、これを使う設定をsshd_configにする。

PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes

パスワード認証とチャレンジレスポンス認証の両方を切ると鍵認証強制になるが、

チャレンジレスポンス認証を有効化した上で、PAM認証とすると、先ほど設定したPAMの認証が使えると。


あとは各ユーザーでGoogle認証システムの設定を行う。

$ google-authenticator -t -d -e 0 -r 2 -R 30 -w 2 -Q UTF8 -l "Libserver SSH"

Google認証システムの初期化にはQRコードを使うと便利なので、qrencodeをインストールしておく。

その上でこのコマンドを実行すると、コンソールに巨大なQRコードが表示される。

これをAndroidまたはiOSにインストールしたGoogle認証システムで読み取ると、

端末にワンタイムパスワードが出るので、これを確認に入力すれば、認証情報が~/.google_authenticatorに格納される。

いろいろオプションを付けたが、これを付けないといろんなことを聞かれるので。

"-t -d"は時間ベースのワンタイムパスワードで同一コードの再利用禁止、

"-e 0"は非常用コードなし、これはGoogle認証システムが使えないときのワークアラウンドは鍵認証と考えているから。

"-r 2 -R 30 "は30秒間に2回まで再試行可能、"-w 2"は最近2回(30秒ごと更新なので1分以内)のコードが有効、

"-Q UTF8"はUTF-8環境でのQRコード表示、-l オプションはGoogle認証システムでの表示名。

なお、QRコードが表示できない場合は、secret keyの文字をアプリに入れるか、相当するQRコードを作ればよい。

GoogleのQRコード生成用URLで生成してもよいが「キーがGoogleに漏れるから注意」と書かれている。


これで、あとは実際にSSHで使うだけ。

Using username "hidemaro".
Keyboard-interactive authentication prompts from server:
| Verification code: (ワンタイムパスワードを入力)
| Password: (Linuxのパスワードを入力)
End of keyboard-interactive prompts from server

まぁこんな感じですね。

この認証方式ってSFTPでも使えるのかなと、FileZillaの設定を見てみたら「インタラクティブ」てのがあるんですね。

これを選ぶと、対話的に2つのパスワードを聞いてくれる。

Pageantに鍵データを読み込んでいれば何もきかれずログイン成立となる。

以前はFileZillaで鍵認証するにはPageantで鍵データを読み込んだ状態で、ダミーのパスワードを設定してたものだが。


これが完了したところで、新しい鍵データを作って、改めて公開鍵を登録し直して、秘密鍵はローカル保存にした。

秘密鍵が使えないときは2要素認証で、Google認証システムが使えないときは鍵認証で、これで安心ですね。

一度ログインできれば、新しい鍵を登録することもできるし、


PAMつながりでもう1つ。

パスワード見直しの一環で、Linuxのパスワードも見直したが、けっこう長いパスワードになった。

ログインするときはよいが、sudoするたびにこの長いパスワードを入れるのはいやだ。

パスワードなしでsudoできるようにしてもよいが、ちょっとなぁと。

そこでsudo用のパスワードを別設定して、数字数桁のPINコードで認証するようにした。

pam_userdb.soというモジュールを使って、別に用意したパスワードデータベースで認証出来るようだ。

ただ、これの使用例を調べると、平文でパスワードをデータベースに格納しているので、それはおかしいだろうと。

$ echo "username" > db.in
$ perl -e "print crypt('xxxxxx',sprintf('\$6\$%08x',rand 0xFFFFFFFF)).\"\\n\"" >> db.in
# db_load -T -t hash -f db.in /etc/sudo_pw.db

ユーザー名とパスワードを交互に書いたテキストファイルを作って、/etc/sudo_pw.db のデータベースに格納するのだが、

pam_userdb.soではcryptされたパスワードを受け入れることも出来る。

じゃあ、どうやってcryptするのかって、perlのcrypt関数を使うのがよいだろうと。

引数の2つ目に暗号化方式とSaltを指定するのだが、"$6$xxxxxxxx"とすると、

SHA512方式(最近のLinuxでは標準)で、xxxxxxxxというSaltを付けて、1つ目の引数を暗号化するという意味になる。

Saltは乱数を16進数表記にすることで8文字作るようにした。こんなもんでいいでしょう。


その上で、/etc/pam.d/sudo にsudo時の認証方式を記載する。こちらはまっさらにして次の通り。
auth       required     pam_userdb.so crypt=crypt db=/etc/sudo_pw
account    required     pam_userdb.so crypt=crypt db=/etc/sudo_pw
session    optional     pam_keyinit.so revoke
password   requisite    pam_cracklib.so try_first_pass retry=3 type=

/etc/sudo_pwというデータベース(dbという拡張子がないことに注意)に、パスワードはcrypt形式で暗号化したので認証と。

keyinit.soはオリジナルの設定、pam_cracklib.soはinclude先のsystem-authにあったから書いたけど、意味があるかは知らない。

あと、sudo実行時に表示されるプロンプトに"password"って書いてあると勘違いしそうなので、

/etc/sudoers (visudoコマンドで編集する)でプロンプトを変更した。

Defaults passprompt="PIN for %u:"

これでPINを入力するように読めるからいいんじゃないかなと。


Author : Hidemaro
Date : 2019/11/30(Sat) 23:45
コンピュータ・インターネット | Comment | trackback (0)

テレビ会議で操作をサポート

ここのところ、社外の試験場に出張している人がいる。

試験開始時はいろいろなトラブルが相次ぎ、当初の計画は早くも崩れたそうだが、

立て直しを図り、なんとか軌道に乗ったと思ったら、なにやらエラーが出たよう。


それで、社内にいるチームリーダーが、こんなことが起きてるんだけど、と相談に来るので、

話を聞くと、どうもエラーは誤爆っぽい。

エラーメッセージを送ってもらって、明らかに誤爆であることはわかった。

それで少し考えたが、設定を変更するとこのエラーを消すことができることに気づいた。

試験項目によってはエラーメッセージを切ることは許されないのだが、

チームリーダーに確認すると、必要な試験はもう終わったとのこと。じゃあ切ろう。


そのためには、試験対象のシステムの設定変更をしなければならないが、

問題は今日、試験場に出張している人は、この設定変更の経験がないということ。

担当者の1人には操作方法を教えたので、E-mailや電話で指示をしてもなんとかなりそうだったのだが、

あいにく今日は出張していないので、そこに期待することは出来ない。


そこでどうしたかというと、テレビ会議を使った。

業務用ノートPCにはインカメラが付いている。それを試験場に持ち出してますからね。

インカメラで、システムにつながっているコンピュータの画面を映してもらったのだ。

幸いにして、今回の試験室は狭く、おかげでLANケーブルを試験室内に引き延ばせて、

インカメラの画質でわかるかどうか心配だったが、操作画面を判別するには十分だった。

やはり画面を見ながら操作を指示すると、的確に指示ができて、これまで経験がない人でもなんとかなった。


コンピュータの画面をインカメラに映すなんて、まどろっこしいことをするんだな、

と思ったかも知れないが、操作用のコンピュータがインターネット接続を想定した設定になっていないんだよね。

社内ネットワークへは明確に接続できない設定なのだが、社外ならそこのポリシーさえ満たせればなんとでも。

ただ、長きにわたりネットワークから切り離され、セキュリティ対策がろくにされていないのと、

社内ネットワークに明確に接続できない理由の1つでもあるけど、

システム用にネットワーク関係の設定をカスタマイズしてるから、なかなか難しいかなぁと。


テレビ会議も慣れだなとは思った。

これでも、普段からインスタントメッセンジャーとして使っているソフトでテレビ会議ができるだけよくて、

以前はテレビ会議対応の会議室同士をつないでやるしかなく、ハードルが高かったようなことも聞いている。

今回みたいに出張先で急遽テレビ会議を開く方法はなかっただろう。

もちろん、現在でも高品質の会議をしたければ専用の会議室で、備え付けの専用システムを使うべきだが、

設定にかかる手間を考えれば、簡易な方法でも実用上問題ないという考えは普及していた。

こんな簡易なので、ちゃんと指示できるかなぁとは思ってたけど、案外いけますね。


Author : Hidemaro
Date : 2019/11/28(Thu) 23:09
コンピュータ・インターネット | Comment | trackback (0)

Tools