2017-04-02 1 views
6

もちろん、パスワードはハッシュされ、元のパスワードは保存されないので、愚かな質問のように聞こえるかもしれません。API秘密はハッシュされるべきですか?

しかし、APIの秘密については、一般的に私はそれらをサインアップするときに明確に表示されます。

たとえば、Googleのapiコンソールにアクセスして自分の認証情報ページを見ると、クライアントの秘密情報をTwitterで見ることができます。

確かに、apiキーはパスワードと同じように敏感ですか?

プロバイダ側からは、十分に強力なパスワードが生成されていると確信できますか? これが当てはまる場合、データベースが侵害されているかどうかは保護されません。

トークンベースの認証を使用している場合は、クライアントのIDとシークレットまたはリフレッシュトークンを使用して資格情報を送信する必要がありますすでに妥協されていなければならないのか?

答えて

4

私はこれにはいくつかの可能な答えを想像することができますいくつかのケースでは

  • を、ユーザビリティの要件(GoogleとTwitterのを満たすために、平文のAPIキーの永続ストレージを持つサーバー用に必要な場合があります例)。
  • 場合によっては、APIキーだけではあまり多くのことを行うには不十分です。さらに、認証されたアカウントが必要です。そのため、APIキー自体が制限されているため(パスワードよりも価値が低くなります) 。
  • 多くの場合、APIキーはクライアントアプリケーション(特にモバイルアプリケーションなど)でハードコードされているため、同じトークンを使用できる場合にはサーバー側に追加保護を追加するのは意味がありませんクライアントから簡単に抽出することができます。
  • セキュリティ業界はまだ成熟していません。たぶん、ハッカーがAPIキーをダンプし始めると、このようなアイデアはもっと真剣に受け止められるかもしれません。

私は最後の点について非常に真剣です。真実は、多くの良いアイデアが、それらの背後にある重大な支持があるまで現実にはならないということです。一例として、以前は関連するトピック - protecting user confidential information by hashing it in the databaseについてブログに書いていましたが、合法的なユーザーがログインしたときに回復できるようになっていました。私はAshley Madisonを例として使用しました。その場合、ハッカーは電子メールアドレス、電話番号、および物理アドレスを入力します。ハッカーがデータベースを奪ったとき、彼らはすぐに自分が望むものを持っていたので、bcryptでエンコードされたパスワードを気にする必要はありませんでした(実際には、古いパスワードの中にはMD5のみでエンコードされていました)。それらを現実にするために押します。現実世界ではゼロ知識のWebデザインですらほとんどありません。

+0

ありがとうございました。私にとっては、クライアントの秘密情報は機密情報であるため、常にハッシュすることを選択します。 これは明らかにAWSがこれを行っている(または間もなくなります)ので、私はそれがおそらく良いアイデアだと思う唯一の人ではありません:) あなたが言ったように、私はGoogleとTwitterはハッシュをユーザビリティの理由から考えて、ユーザベースを考えればそれはいくらか理解できる(しかし、彼らの大きさでさえ私は好まないだろう)。 モバイルクライアントについての良い点は、javascript apis(クライアント上の秘密が制御できなくなっている)にも当てはまります。 – Steviebob

関連する問題