私は、ユーザー名とパスワードを読み込んで保存しておいて、プログラムが後でその内容を読み取れるようにするアプリケーションを作成しています。いくつかの変数にそれを格納することは、愚かな考えのように聞こえる。アプリケーション内にパスワードを保存する
KDE libraryが見つかりましたが、依存性があまりにも大きいので、使い方が分かりにくいプログラマです。
パスワードを保存する一般的な方法は何ですか？また、問題をどのように解決できますか？
これは情報によって何をするかによって異なります。
外部サービスにアクセスするために名前とパスワードを使用する場合（ただし、次回のプログラム実行時にユーザーが情報を再入力する必要があります）、変数をいくつかの変数に格納することはOKです。コアダンプなどには表示されないように、少なくとも暗号化されたパスワードを暗号化して保存することをおすすめします。パスワードが必要なときは、それを復号化して使用し、復号化されたバージョンが保存された場所（zapping）に上書きします。 （注：このコンテキストでは、ハッシュは適切ではなく、パスワードを見ることができ、ハッシュを元に戻すことはできません）。プログラムの外部に情報を格納することもできますが必要ないと思われる。バイナリにはまだ暗号化キー（および暗号化アルゴリズム）が含まれており、暗号化されたデータはプログラムの平均内容よりもランダムなので、実際には暗号化されたパスワードを隠すことは実際には非常に困難です。しかし、あなたは決心して、最も決定的な攻撃者以外のすべてを止めることができます。
ユーザー名とパスワードを永続的なレコードとして保存して、同じユーザーが将来情報にアクセスすることを検証できる場合は、プログラムの外部に記憶域を使用する必要があります。並行性の問題を確実に解決するには、単純なデータベースを使用します。この場合、あなたはいくつかのsaltでパスワードをハッシュし、ユーザ名と塩とハッシュパスワードを保存して、ユーザ名があれば他の2つの値を簡単に見つけることができます。
ナイトウォーカーのコメント：
私はいくつかのWebデータベースにアクセスするためにそのパスワードを使用するので、私はそれが最初に入力された後、それは自分のアプリケーションに保存されている必要があります。プレーンテキストのファイルがそのアイデアをスマートにしていると確信していますか？
「アプリケーションに保存されている」とはどういう意味ですか。実行可能ファイルを変更することはできませんし、少なくとも実行しようとするべきではありません。したがって、アプリケーションの実行可能ファイルとは別のファイルに保存されている永続的なレコードと見なす必要があります。一方で、あなたは、私が概説したものとは異なる問題に直面しています。あなたはその情報でユーザを認証していません。オンデマンドで情報を復号化して他のアプリケーションに送信する必要があります。
まず、塩とハッシュは関連性がないことを意味します。マスキング操作を元に戻す必要があり、ハッシュを元に戻すことはできません。
次に、再表示時にアプリケーションのユーザーを特定する方法を決定する必要があります。ユーザーは自分のデータにアクセスするためにパスワードを入力する必要がありますか、または単にオペレーティングシステム特権やその他のスキームに頼っていますか？
ユーザーがアプリケーションにパスワードを入力する必要がある場合は、ユーザー名を暗号化するために、そのパスワード（またはアプリケーションのパスワードを認識するためのパスワードハッシュとは別のハッシュ）を使用することを検討できます/外部アプリケーションのパスワードの組み合わせ。次に、ユーザー名と、引数として、暗号化されたパスワードのBase-64でエンコードされたバージョンをテキストファイルに格納できます。これは、オリジナルの塩詰めされたハッシュ形式で格納されているアプリケーションパスワードと同じくらい安全です。ユーザーが戻ると、アプリケーションのユーザー名とパスワードを入力する必要があります。その組み合わせを格納されている値と比較し、そのパスワードを使用して外部アプリケーションへのパスワードを解読できます。
ユーザーがパスワードを入力しなかった場合、あなたのできることはより制限されます。使用可能な情報から何らかの形で鍵を決めることができなければなりません。これは、ユーザの暗号化されたパスワードを、ホームディレクトリの下にあるサブディレクトリ（グループまたはパブリックアクセスなし）などの制限された場所に保存できます。
mkdir ~/.appname
chmod 700 ~/.appname
cp /dev/null ~/.appname/app.key
...store the encrypted information...
chmod 500 ~/.appname
chmod 400 ~/.appname/app.key
ユーザーの名前の固定キーを組み合わせた場合でも、たとえば、チャンスは誰かがそのキーが何であるかを仕事（と暗号化技術）と、それをリバースエンジニアリングすることができますということですので、これはあまり満足のいくものです。 （暗号化されたデータの秘密は鍵に依存しており、鍵はプログラムによって決定可能な場合には、決定された攻撃者によっても決定されます。実行時にフレーズ）を通過し、その後、アプリケーションは、攻撃者がオフラインで使用できるものを保存しません
どのような用途ですか？多くの方法がありますが、ASP.Netの場合はweb.configファイルで暗号化するのが一般的です。
クロスプラットフォームのC++アプリケーションです（一部のWebアプレットではありません） –
通常、ユーザー名とハッシュバージョンのパスワードを保存します。このウィキペディアの記事を参照してください。hash functions、およびquestion
後で実際のパスワードを使用してリモートシステムなどにログインする必要がある場合は、パスワードのハッシュは役に立ちません。 –
絶対に..... – Peter
何MySQLやSQLiteの約なし、パスワードをハッシュと永続的なデータベースに格納
共通。？？後で使用するためにパスワードを保存する方法は、いくつかの暗号化されたキャッシュに保存することで、キャッシュはいくつかのマスターパスワードを使用して暗号化されます。個人データ（ユーザ名、p asswordsなど）は、軽いインターフェースを持ち、クロスプラットフォームであり、GNU General Public Licenseの条項の下で公開されています。あなたはそれをサンプルとして確認し、その一部を使用することができます。
spotep.comには、ユーザー名とハッシュコードとパスワードの組み合わせが保存されます。これの利点は、シンプルなパスワードが同じハッシュコード（Cookieに格納されているため、非常に危険な状態になる）が発生しないことです。
すてきなウェブサイトがありますが、そこにたくさんのシリーズがありません カプリカ、バトルスターガラクティカ、アナーキーの息子など... –
うん、私たちはいませんか？ –
SQLiteにハッシュパスワードを保存することをお勧めします。その後、パスワードをチェックする必要があるときはいつでも、それをハッシュして、それを保存された値と比較してください。これにより、保存されたパスワードを安全に保ち、誰も（自分でさえ）自分が何であるかを知ることができなくなります。
プラットフォームに依存しないアプリケーション設定を永続的に提供するQSettingsをお試しください。 mysqlのようなソリューションは、保存するパスワードが何百もある場合を除き、過剰なものになります。
私はそのパスワードを使っていくつかのWebデータベースにアクセスしていますので、初めて入力した後にアプリケーションに保存する必要があります。 プレーンテキストファイルはそのスマートなアイデアですか？ –
私はそれが永久記録は今まで最高のアイデアだと思うので。 アプリケーションには他のパスワードがありません。他のユーザーがそのアプリケーションを使用することはありません。 唯一の事は他のpplからのパスワード+ユーザー名を救い出そうとすることです。 –
はい、情報をいくつかの永久ファイルに保存する必要があります。アプリケーションのユーザーごとに個別のファイルを使用します。 Base-64エンコーディングで暗号化されたパスワードを保存してください（プレーンテキストファイルなので）。暗号化に使用される鍵を、ユーザーの最も信頼できる特性（おそらくユーザー名とユーザーID番号と固定テキストの連結）の暗号化ハッシュから導き出し、安全なものとして保管しますあなたが考案できる場所。セキュリティは完全ではありません。攻撃者が発見できるものは何ですか？ –