前回の記事では、認証器として指紋認証付きのスマートフォンを利用してパスキーによる認証を体験しました。その後、Google が販売する FIDO セキュリティキーである Titan Security Key を購入したので、そちらを使うパターンのパスキー認証を試してみました。
今回も WebAuthn.io のデモページを利用させてもらいます。
まず登録です。セキュリティキーをUSBポートに挿しておきます。
ユーザ名を入力して”Register”を押し、パスキーの作成方法として「USBセキュリティキー」を選択します。
セキュリティキーをタップします。
登録完了です。物理的に接続されている分、スマートフォンを利用する場合に比べてステップが少なくて済みます。
次に認証。
ユーザ名を入力して”Authenticate”を押し、セキュリティキーをタップします。
認証成功です。
ユーザ登録を実行したPC以外でも、セキュリティキーを挿しさえすれば、非常にスムーズにログインできます。
スマートフォンで認証を行う場合はセキュリティキーを NFC デバイスとして利用します。
ユーザ名を入力して”Authenticate”を押します。
セキュリティキー使用の確認画面が出るので「開始」を押します。
「NFCでセキュリティキーを使用する」を選択します。
セキュリティキーをスマートフォンのNFC読み取り箇所に当てます。
正しく読み取れたら認証完了。
PCでは認証器としてスマートフォンを使うよりもセキュリティキーを使う方が、全体的に手順が簡略に済みます。
ただ、スマートフォン自体で認証を実行するときにはスマートフォン自体の生体認証を使う方が楽なのは間違いないです。一つのアカウントで一つの認証器でしか登録できないということはないので、両方で登録しておいて状況に応じて使い分けるのが便利かなと思います。
ここ最近、部署間の異動で広報業務を兼務するようになりました。簡単に言うならプレスリリースやメルマガなどを作成する訳なんですが、なにせ初めて携わる種類の業務なので、
と言った素朴な疑問が浮かびます。
どんなことでも基礎的な型や手法が確立されているものですし、それを学ぶことでその分野の全体像がなんとなくわかったり、成長までの道筋やどのような考え方で取り組めばいいのかがわかります。ただ闇雲に進むのではなく、何か道しるべが欲しい。そこで手に取ってみたのがこの書籍。
ひとり広報の戦略書 – 認知と人気を全国レベルにする「知ってもらえる」すごい方法 –
小野茜 (著)
著者の小野茜さんは、企業で5年間広報を担当しPR支援会社を設立。現在は、企業の外側から「広報」をサポートする仕事をされていて、実際に30社以上の様々な企業で広報業務をサポートされてらっしゃるそうです。広報とはなんぞやというエピソードやノウハウが詰まっていて大変勉強になりました。
この記事では、本書で私が気になった箇所や良かったところをピックアップしてみましたので、同じような境遇でお困りの方に届けばいいなと思います。
まずこの書籍を読んでみてわかったことが「広報をひとりや少人数でやっている企業が大半」ということ。著者が様々な企業に入って広報業務のサポートをされてるからこそ見えてくることですし、様々な企業の広報担当が悪戦苦闘している状況があるから、こんなタイトルで刊行することになったんだろうなと思います。
更には、以下のような悩みを抱えている方が多いようで、私ひとりじゃないんだなと少し安心しました。
ひとり広報を取り巻く状況は厳しいですが、メディアの多様化・細分化により、テレビや新聞などのマスメディア活用は限定的になった昨今、様々なネタやコンテンツが求められていたり、地方の小さな企業のニッチなネタでもメディアに取り上げられることも多く、著者は「広報活動をする上でベストな時代」であると言います。ひとりであることは逆に強みでもあると。
では、ひとり広報にはどんな強みがあるのでしょうか?
ひとり広報のメリット
ひとり広報のデメリットは?
「ひとりで全てをやるため、特に片手間で対応している場合も多いと思いますので、業務に追われて成果がでない」やはりここが最大の壁のようです。そのためにはどうすればいいのか?
要するに実行するタスクを見極めて質より量で回すことしかなさそうではあります。
目安としては、最低でも週に1本計算で月4本配信できていれば積極的な広報活動が行えているようです。
広告が「対ユーザーに対して購買につながる」が最重要な目的であることに対して、広報=PR(Public Relations)は社会とのつながり(関係性)をつくることが目指すべきものであると言います。「対ユーザーに対して購買につながる」だけでなく、「対メディアに対して取材につながるネタを提供」して関係作りも狙えることは素敵なお仕事だなと思いました。
一番大切なことは「自社にとって必要な広報活動を見つけ出し、実践する」ではありますが、PRの本質として関係を作るためには、情報を伝達するだけでなく、面白いプレスを打つことで社内外に魅力を伝えることも重要な要素だそうです。
だからこそインプットが大切だと。目と耳の両方で、ツールを駆使してインプットの時間を作る。あらゆることに「なぜ」「どうして?」と、ちょっとした情報でも背後に何が起きているのかを意識する。そういった積み重ねで時代の流れを掴むことができるのかもしれないです。
そういえば最近、雑誌の「meets」 で焼肉の特集が組まれてました。これも何か意図や流れがあるかもしれませんね。
コロナ以降、費用対効果の高いウェビナーの活用などオンラインでの活動も盛んになってきていて広報業務の裾野は広がっているのではないでしょうか。ひとりで頑張る担当の方々と情報の共有というカタチでつながりができればと思い記事にしてみました。
弊社が提供するWebサービスについてもプレスリリースを定期的に行なっておりますので、興味を持ったメディアやライターの方がいらっしゃればお話させていただければ幸いです。
こんにちは。開発担当のマットです。
今回の記事で、ウェブサービス等の開発者がパスワードを安全に保存するための塩かけ(ソルト)の概念を説明したいと思います。
大昔、ウェブサービスにアカウントを作成した際、そのウェブサービスが登録したユーザ名とパスワードをそのまま保存しました。
データベースを覗いてみると、各ユーザのユーザ名とパスワードはそのまま見れていました。
user_name | password |
田中 一郎 | 123456789 |
山田 太郎 | hogehoge |
鈴木 花子 | qwertyuiop |
村田 次郎 | hogehoge |
もちろん、サイトがハッキングされてしまった場合、全ユーザのパスワードが丸見えです。
これを使って、ログインすることもできますし、ユーザ様が別のウェブサイトで同じパスワードを利用している場合、そのウェブサイトにもログインされてしまうことは考えられます。
とても、不安全な方法でした。
こういう問題が明らかになった時、多くのウェブサービスがハッシングを使うようになりました。
ハッシングとは一方的の暗号関数です。
その関数にパスワードを渡したら、暗号された文字列が生成されます。
いくつかのハッシング・アルゴリズムは存在しますが、md5 というものを使ってみると、”hello” が “5d41402abc4b2a76b9719d911017c592” に変換されます。
特徴として、似たようなものを暗号化しても、その結果(ハッシュ)が全然違います。
例:
“bat” => 5f3f4681121b460e3304a1887f42f1c3
“cat” => d077f244def8a70e5ea758bd8352fcd8
“あいうえお” => 86deb27a32903da70a7b2348fcf36bc3
“あいうええ” => 5c6a3a46075a5617cd570ee1c583e528
パスワードを直接データベースに保存する代わりに、パスワードのハッシュを保存する時代になりました。
user_name | password |
田中 一郎 | 25f9e794323b453885f5181f1b624d0b |
山田 太郎 | 329435e5e66be809a656af105f42401e |
鈴木 花子 | 6eea9b7ef19179a06954edd0f6c05ceb |
村田 次郎 | 329435e5e66be809a656af105f42401e |
ユーザ様がログインする際、入力したパスワードを同じアルゴリズムでハッシングして、データベースで保存されているものと一致する場合のみ、正しいパスワードと言えます。
この方法で、データベースにパスワードを直接保存することなく、ウェブサービスを作ることはできるようになりました。
…ところで、ちょっとした問題はまだあります。見えますでしょうか?
上記の例で、山田 太郎さんと村田 次郎さんは同じパスワードを使いました。
同じパスワードを使っているため、ハッシュも当然同じです。
つまり、サービスがハッキングされてしまった場合、パスワードはバレませんが、「山田 太郎さんと村田 次郎さんは同じパスワードを使っています」というのがバレてしまいます。
もし、山田 太郎さんのパスワードが別の方法でバレてしまった場合、村田 次郎さんのパスワードもわかってしまいます。
あと、多くのユーザ様がいる場合、重複が多いパスワードを推測することも可能になります。
“password1” や “12345678” など、多くの人が使いそうなパスワードはあるので、重複数が多いユーザはこういうようなパスワードを使っていると言えますね。
調理する時、塩を少し加えるだけで味がグッと変わりますよね。
同じく、ハッシングをする時、パスワードだけではなく、「ちょっとした何か」を加えると、全く違う結果になります。
例として、2人のユーザが同じパスワード (“password123”)を設定するとします。
そのままハッシングすると、2人とも同じハッシュになりますが、ユーザAのパスワードに「abc」を付け加えてからハッシングして、ユーザBのパスワードに「xyz」を付け加えてからハッシングすると、2人とも全く違うハッシュになります。
この「ちょっとした何か」を「ソルト」と呼んでいます。
ソルトは乱数でも、ランダムな文字列でも大丈夫です。とにかく全てのユーザに違うソルトが振られたら問題ありません。
そうすると、仮に全員が同じ「password123」を設定したとしても、データベースに保存されるパスワードが全く違います。
user_name | salt | password |
田中 一郎 | PJTBCTwz | a021144f7dec828d515f372d6d239f5f |
山田 太郎 | 5g0VkWF1 | 19ead4c6deca667db146d9a1c478e4d6 |
鈴木 花子 | p9nfzkBT | 411fec4ff70554cded8b48ab9bc3b8c3 |
村田 次郎 | BoqWcL59 | 5487529bd4deb8003b6a46bbbaf03332 |
ユーザがログインする時、入力したパスワードにソルトを付け加えてハッシングすると、その結果が password として保存されている値と同じ場合、ログインをさせるという処理になります。
ご利用のウェブサービスが正しくソルト付けとハッシングをしているかどうかは判断しにくいですが、「パスワードを忘れました」などのリンクを押した場合、自分のパスワードがメールで送信されたら、安全に保管されていないと言えます。
パスワードを正しく取り扱っているウェブサービスはユーザのパスワードをわかる方法がないはずです。どこにも保存してはいけないデータとなります。
なので、ウェブサービスが自分のパスワードをメールで送信できる場合…アウトです。
ご注意ください。
こんにちは。開発担当のマットです。
僕はプログラミングが大好きです。パソコンに自由自在にコマンドを書いて、好きなものを作れることはとても面白くて、プログラマーになった理由です。
しかし、プログラムの書き方に気を付けないと、規模を拡大することに連れ、処理がカクカクと遅くなってしまうこともあります。
この記事にて、プログラマは常に気を付けなければならない Big O 記法を紹介したいと思います。
Big O 記法 (別名: オーダー記法、O-記法、ランダウの記号) はドイツの数論家であるポール・バッハマンによって1894年に、彼の著書『解析数論』(Analytische Zahlentheorie) の第二巻で初めて導入されました。これに触発されてエドムント・ランダウが1909年に発明しました。
「どういうもの?」かというと、何らかの関数(何らかの機能)の規模を大きくするに連れ、その関数の処理時間がどのように伸びるか、の表記と考えてもいいかもしれません。
ゲームの例で考えましょう・・・
特定のゲームではなく、たくさんのAIプレーヤが遊ぶ戦略ゲームとか、何でもいいです。
このゲームで、プレーヤーが順番に遊びます。
ゲームのメモリーに、プレイヤーの順番リストがあるとしましょう。
ゲームに4プレーヤーがいるとしましょう。
では、ゲームの一番目のプレーヤーを見つけるのに、どれぐらい時間がかかりますでしょうか?プログラムがしないといけない処理は:
・まず、プレーヤーのリストを見る。
・リストの頭のプレーヤを引き出す。
・終わり。
簡単な処理ですね。さて、プレイヤー数をなんと 10,000人にしたら、その処理がどうなるでしょう?
・まず、プレーヤーのリストを見る。
・リストの頭のプレーヤを引き出す。
・終わり。
変わりませんよね。Big O 記法では、こういう関数を O(1) と書きます。
O(1) とは、定数時間。関数に突っ込むデータの規模が大きくなっても、処理時間が変わりません。
プログラムを書く時(特に、大規模のデータを処理するプログラム)、O(1)の関数ばっかりでできることは一番望ましいです。
次、各プレーヤに100ポイントを与えましょう!
4人のプレイヤーがいる場合、
・まず、プレーヤー1に100ポイントを与える
・次、プレーヤー2に100ポイントを与える
・次、プレーヤー3に100ポイントを与える
・次、プレーヤー4に100ポイントを与える
・終わり。
簡単な処理ですが、10,000人プレーヤーがいるとしたら、その人数分の時間がかかりますよね。これは O(n) と書きます。
規模が大きくなるに連れ、その分遅くなります。データは2倍あるなら、処理は2倍遅い。
次、少し難しくなりますが、このゲームに「隠れ情報」があるとしましょう。
例えば、各プレーヤーの財産が自分にも、他人にも、見られないというルール。
もちろん見られませんが、賢いAIを作るには、自分と他プレーヤーの財産を推測する関数も作りたいですね。
・まず、プレーヤー1が自分の財産を推測する。
・次、プレーヤー1がプレーヤー2の財産を推測する。
・次、プレーヤー1がプレーヤー3の財産を推測する。
・次、プレーヤー1がプレーヤー4の財産を推測する。
・次、プレーヤー2がプレーヤー1の財産を推測する。
・次、プレーヤー2が自分の財産を推測する。
・次、プレーヤー2がプレーヤー3の財産を推測する。
・次、プレーヤー2がプレーヤー4の財産を推測する。
・次、プレーヤー3がプレーヤー1の財産を推測する。
・次、プレーヤー3がプレーヤー2の財産を推測する。
・次、プレーヤー3が自分の財産を推測する。
・次、プレーヤー3がプレーヤー4の財産を推測する。
・次、プレーヤー4がプレーヤー1の財産を推測する。
・次、プレーヤー4がプレーヤー2の財産を推測する。
・次、プレーヤー4がプレーヤー3の財産を推測する。
・次、プレーヤー4が自分の財産を推測する。
数えると、 4 プレーヤーで 16 ステップが必要です。
8プレーヤーだとしたら、64ステップが必要になります。
規模を2倍にすると、4倍の処理時間となりますね。
平方関係なので、O(n²) と書きます。
限りなく、他にもたくさんの表記があります。
O(n³) もありますし、 O((n-1)²)もあります。
O(log n)もありますし、恐ろしい O(n!) もあります。
それぞれのBig O 記法の表記の意味を暗記する必要はありませんが、プログラマーとして、何かの関数や機能やアルゴリズムを作るとき、無駄に時間が掛かるやり方でやっていないか、気を付けなければならないと思います。
この Big O 記法を常に頭にいれて開発をすると、より速やかで優れているコードは書けると思いますので、今後もこの記法を覚えてプログラミングをやっていきたいと思います。