自前で認証システムを作るのは危険なのでしょうか？

認証システムはよくライブラリや外部サービスを使っているケースが多いように感じます。
例えばRubyのdevise、Auth0など

しかしシンプルな認証システムを自前で作成することは危険なのでしょうか？

例えばですが、

メールアドレスとパスワードでログイン
パスワードはハッシュ化して保存し、ハッシュ値が同じであれば認証成功とみなす
認証成功後はブラウザのcookieに認証情報を暗号化したものを保存し、以後そのcookieをみて認証済みかどうか判断する

上記のような一般的な認証システムを実装することはそこまで大きな労力には感じませんが、それをすることで冒頭に挙げたようなライブラリや外部サービスを使うより危険なことがあるのでしょうか？

行動規範の内容に同意します

回答5件

上記のような一般的な認証システムを実装することはそこまで大きな労力には感じませんが、それをすることで冒頭に挙げたようなライブラリや外部サービスを使うより危険なことがあるのでしょうか？

要件定義や設計が完了しているのであれば、確かに労力はそれほどかからないと思います。
が、認証システム(というか、会員管理システム)は適切に設計することすら大きな労力を伴います。

システムのセキュリティ精度を一定以上に保つためには脅威分析を行わねばならず、脅威分析を行うには、脅威自体を網羅的に知る必要がありますが、この「網羅的に脅威を知る(洗い出す)」という行為が非常にハードルが高いです。
情報の性質として仕方ないのですが、クローズドな情報として扱われるケースが多く、この部分において、セキュリティの専門家と一般エンジニアの持つ情報量の乖離は絶望的です。。。

シェアの大きなフレームワークや有名ライブラリでは、この部分を集合知で乗り切ろうとしています。
コードをオープンにすることで、クローズドな情報も持った方からも実装の提案を受けやすくし、「それなりに安全なシステム」として成立できる程度を結果として保てるようになります。

ごく一般論としてですが、集合知によってなされたコード群の背景にある要件は、一般システムの持つ要件を包括しています。そのため、(ホントに要件を満たしているかの確認は必要ですが)自前で実装するよりもはるかに安全に使用することが可能です。

個人的には、フレームワークやライブラリが、その実装の背景にある要件や設計を明文化していないケースが多いのが不満ですが、それでも実利を考えると、フレームワークの使用やライブラリの使用をオススメします。

投稿2020/08/20 07:46

退会済みユーザー

総合スコア0

退会済みユーザー

2020/08/20 07:53 編集

ただ、フレームワークやライブラリの使用方法を間違って、逆に穴をあけてしまうってケースもあるんですよね。。。重要部分はちゃんと一度は理解しておきたいですね。

行動規範の内容に同意します

一昔前では、自前で作るのが当たり前だったわけですから、
アプリケーションを作る事自体はそんなにハードルは高くないでしょう。
ノウハウなどを勉強するための情報も、十分にあると思います。
どうしても不安なら、セキュリティに強い会社に相談してもいいでしょうし。

結局、運営側で一番嫌な事ってのは、**「個人情報を自分たちの管理下で持つ」**ってところなんですよね。
クレデンシャルの情報もそうですし、カード番号などもなるべく持ちたくありません。
アプリがセキュアでも内部の人間が業者に売り飛ばすかもしれませんしね。
そういう意味でも、外部に委譲した方が楽な事が多いってだけです。

あと、TwitterやFacebookなどの有名なサービスでのOAuthが用意されていると、
ユーザーの会員登録へのハードルが下がるという効果もあるかもしれませんね。

投稿2020/08/20 05:53

編集2020/08/20 06:37

root_jp

総合スコア4666

危険になるかどうかは質問者さんの技量次第です。
例えば、攻撃方法や防御方法を熟知した上で作成するなら、既存のより圧倒的に柔軟性の高いのができると思いますが、それらを持ち合わせていない・自信がないなら避けるのが無難だと思います。

投稿2020/08/20 05:18

kyoya0819

総合スコア10429

kuuritar

2020/08/20 05:20

なるほど、ありがとうございます一般的に広く使われているものはそういった攻撃などを考慮されているということですね。１例でも良いので、想像できる攻撃などあればおしえていただけないでしょうか。

kyoya0819

2020/08/20 05:24 編集

どのようなツール、規格を用いるかによって異なってきますが、 SQLインジェクションやセッションハイジャックなどが有名だと思います。その他にもいろいろありますので、セキュリティを学んでみると良いと思います。

退会済みユーザー

2020/08/20 05:25

ごく一般論で、以下が問題となります。 > メールアドレスとパスワードでログイン昨今の傾向として、無対策だと辞書攻撃に弱いです。 > パスワードはハッシュ化して保存し、ハッシュ値が同じであれば認証成功とみなすハッシュ化だけであれば、漏洩時にレインボーなやつでサクッと解析されます。 > 認証成功後はブラウザのcookieに認証情報を暗号化したものを保存し、以後そのcookieをみて認証済みかどうか判断する cookie に情報を持たせた場合、暗号化手順によっては解析可能です。これは、session id だった場合も同様です。

kuuritar

2020/08/20 05:31

詳しくありがとうございます。確かに解析された場合の対策、もしくは認証突破後のプラスαが必要そうですね

miyabi_pudding

2020/08/20 06:27

あと、パスワード暗号化 + アクセストークンを生成するのがトレンドになっていると思います。フロントエンドフレームワークの普及で、APIを使用する機会が増えているため、ログイン後の、各API実行は、ハッシュ認証を必ず行うようにする方式です。 te2jiさんの仰るものプラス、ユーザーに入力させるパスワードはログイン時のみで、その後は発行されたアクセストークンによって認証かける方式です。

行動規範の内容に同意します