「必ずしも~してください」という日本語

YouTubeでガジェットを調べていたら、出演者が「これをする場合は、必ずしも●●してください」と言い出した。

はて、『必ずしも』は打ち消しの語を伴うはず。「必ずしもしてください」という日本語は正しいのだろうか?

などと考えていたら、肝心の箇所を見逃した。結果、二度観る羽目になった。

PV稼ぎを狙って仕込まれたトリックにまんまと引っかかったのだろうか。

パスワード強度評価ツールzxcvbnをC#で使う

年始から始まったデジタルのアカウントの処分ですが、日本の金融系(銀行、証券会社、クレジットカードなど)のウェブアプリのパスワードの弱さが気になります。

特に、ニッセイ確定拠出年金などは「半角数字4~7桁」とのこと。ニッセイ確定拠出年金は出来れば付き合いをやめたいです。

mrgchr.hatenablog.com

「最大長が7文字」などは今の時代にはそぐわないパスワードの制限ですが、一方でSBI証券のように「記号を2種類入れなければならない」などというのも好きになれないものです*1

パスワード設定時にパスワード強度評価ツールで計算したパスワードの強度を示して、ある一定以上のパスワード強度であればパスワードとして受け入れる、などしてほしいものです。

(あるいは、弱いパスワードを入力したユーザーにリスクがあることを促す、など)

パスワード強度評価ツール zxcvbn

パスワード強度評価ツールはDropboxにより開発されたパスワード強度評価ツールです。

github.com

roboformやbitwardenのパスワード強度評価にも利用されているそうです。

www.roboform.com

bitwarden.com

C#での実装で遊ぶ

zxcvbnのオリジナルの実装はJS(CoffeeScript )で書かれていますが、ありがたいことにC#での実装があったので、これで遊んでみます。

github.com

使い方も非常に簡単です。パスワードの強度に応じて Score が0~4の5段階で計算されます。

      int CalcPasswordZxcvbnScore(string password) => Zxcvbn.Core.EvaluatePassword(password).Score;

      CalcPasswordZxcvbnScore("password");
      //=>0

      CalcPasswordZxcvbnScore("password123");
      //=>0

      CalcPasswordZxcvbnScore("p@ssw0rd123");
      //=>1

      CalcPasswordZxcvbnScore("9vpwBRVg");
      //=>2

      CalcPasswordZxcvbnScore("btn!EsT7");
      //=>2

      CalcPasswordZxcvbnScore("TiEpmAQk3y");
      //=>3

      CalcPasswordZxcvbnScore("4iHMaCmBp72Q");
      //=>4

      CalcPasswordZxcvbnScore("B5X2McQGcMj2P$x5$5#y");
      //=>4

興味深いことにRoboformでは「良い(上から2番目の評価)」だったパスワードが zxcvbn-cs では4(最高評価)となることもありました。

この辺りは各社独自の工夫がなされているのでしょうか。それとも実装依存の部分なのでしょうか。

ともあれ、非常に簡単に使えるので、パスワードを設定するUIではこういうものでユーザー側にフィードバックするのはとても良いものだと思います。

*1:そんなルールを強いられたユーザーはどう行動するかというと、紙に書いて保存するでしょう

「今、話しかけてもいいですか?」と聞かれた話

オフィスでコーディングをしていたら、若い同僚に「今、話かけてもいいですか?」と聞かれた。

はて。『今、話かけてもいいですか?』と聞く時点で、それはもう話かけている。

もしワイが『ダメです』と言ったらその発言は撤回されるのだろうか?

スマリヤンの論理パズルみたいだな。

と思いながらも「いいですよ」と返事をした。社会はままならないものである。

Kindleの請求がクレジットカードの履歴に大量に残るので工夫する

電子書籍サービスはアマゾンKindle楽天Koboを使っている。

Koboは複数の書籍をまとめて決済できるが、Kindleは1冊ごとに決済される。

よって、クレジットカードを利用しているとクレジットカードの請求履歴は以下のようになる。

さすがに多すぎである。8月26日は11回も請求が届いている。クレジットカードの履歴をチェックする作業も大変になる。

「こんなに本を買って全部読むの?」という意見は無視する。そういうことではないのである。

特に巻数の多いマンガなどを一気に買うとクレジットカード履歴がアマゾンキンドルで埋め尽くされる。まさに履歴汚染と言っても過言ではない。

現状、アマゾンKindleの購入にはカート機能が無い*1ため、自分でクレジットカードへの減らす工夫をする。

ギフトカードでもKindleは買える

Kindleはアマゾンギフトカードでも買えるので、Kindleを買う前にギフトカードを買ってクレジットカードへ請求を行かないようにすればよい。以上。

「買う本を少なくすればよい」とか「他の電子書籍サービスで買えばよい」と言った意見は無視する。そういうことではないのである。

以下は、ギフトカードでコミックを20冊程度買ったときのものである。50%ポイント還元だったのですべてポイントで支払ったものは記録されていない。

クレジットカードの履歴はこれでスッキリ。気分が良い。

*1:まとめて購入する機能がセール時にあったりするが使ったことはない。おそらく請求は個別にされるのではないか → その後、使ってみたら合算された

SBI新生銀行はSMSで自分の名前を明かさないので自らセキュリティリスクを上げている

SBI新生銀行のウェブアプリで住所などの登録情報を変更をしようとすると、SMSでワンタイムコードが送信される。

が、このメッセージに「SBI新生銀行からのメッセージですよ~」と書かれていないので、どこから送信されたか分からず逆にセキュリティリスクが上がっている。

これを設定した人は自分の事しか見えていなかったんだろうな、と思う。世の中には他人もいるという事を知った方がよい。

割とありがちなミスだが、「銀行って何重もチェックさているんじゃないの?」と割と不安になる。

とりあえずSBI新生銀行には連絡しておいたけど、たぶん無視されるだろうなー。

デジタルアカウント整理における何の価値も生んでいないやり取りについて

今年になってから、利用していないウェブサイトのアカウントを引き続き整理している。

mrgchr.hatenablog.com

ここ数年で、プライバシー保護とセキュリティの強化が今まで以上に重要視されるようになっており、各サイトにほとんどの人は読みもしない注意書きが溢れるようになった。

数年間使っていないサイトのアカウントを消そうとすると以下のようなことが起こる。

  1. ワイ「このサイト数年間使ってないや。今後も使うことはないからアカウント削除しよ」

  2. サイト「セキュリティ強化のため以前のログイン方式は利用できなくなりました。パスワードを変更してください」

  3. ワイ「ご苦労様です(すぐにアカウント消すけど)」

  4. サイト「メールアドレスにメールを送信しました。メール内のリンクにアクセスしてアカウントを承認してください」

  5. ワイ「ご苦労様です(すぐにアカウント消すけど)」

  6. サイト「アカウント承認が完了しました。引き続きサイトをご利用ください」

  7. ワイ「無駄なやり取りご苦労様です(アカウント削除ぽちー)」

セキュリティは大事だね。でも、このやり取りはなんの価値も生んでいないね。社会はままならないものである。