パスワードをソースコードに保存せず、App.Config（またはWeb.Config）内の保護されたセクションに保存します。
この Microsoft Doc の保護された構成を使用した構成ファイルセクションの暗号化セクションを参照してください
これは、組み込みのWindowsのものを使用して暗号化キーを暗号化し、Macアドレスやその他のさまざまな文書化されていないものにロックすることで機能します。
これは、複数のサーバーを使用している場合でも機能します。
... Webファームなどの複数のサーバーで同じ暗号化された構成ファイルを使用する場合、RsaProtectedConfigurationProviderのみが、データの暗号化に使用される暗号化キーをエクスポートし、別のサーバーにインポートできます。
これを使用すると、誰かがパスワードを取得したい場合、最初にサーバー上のWindowsセキュリティを破る必要があります（不可能ではありませんが、パスワードをILで調べるよりも困難です）。
気にしないでください。
できることは何でも、攻撃者は簡単に元に戻すことができます。
ただし、1台のマシンでのみ実行する必要がある場合は、 ProtectedData class を使用できます。これにより、そのマシンやユーザー以外のユーザーから安全に保護されます。
一般に、これを行うためのリモートで安全な唯一の方法は、キーを別の安全な場所に保存することです。
たとえば、パスワードの（非MD5）ハッシュを使用して暗号化してから、ハッシュを取得できるようにユーザーにパスワードの入力を要求できます。 （ハッシュとパスワード自体はどこにも保存されません。パスワードを確認するには、別のハッシュを作成する必要があります）
実際、App.ConfigまたはWeb.Configの「保護されたセクション」機能を使用して、コードにパスワードを保存するよりも安全性が低いと考えています。
サーバーにアクセスできる人はだれでも引用する記事で説明されている復号化コマンドを実行することで、暗号化するのと同じくらい迅速に設定のそのセクションを復号化できます
aspnet_regiis -pd "connectionStrings" -app "/SampleApplication"
https://msdn.Microsoft.com/en-us/library/zhhddkxy.aspx#Anchor_1
そのため、ASP.Netのこの機能は、ハッカーが何らかの方法でweb.configにアクセスしたが、サーバー全体にアクセスできなかった場合にのみセキュリティを追加します（ 201 as @ djteller Oracleパディング攻撃のコメントで言及されています）。ただし、サーバーにアクセスできる場合は、1回のcmd呼び出しで公開されます。 ildasm.exeをインストールする必要さえありません。
ただし、コードに実際のパスワードを保存することはメンテナンスの悪夢です。そのため、web.configに暗号化されたパスワードを保存し、コードに暗号化キーを保存することを確認しました。これにより、メンテナンスが可能な状態で、パスワードをカジュアルブラウジングから隠すという目標が達成されます。
この場合、ハッカーは少なくともコードを逆コンパイルし、キーを見つけて、使用している暗号化アルゴリズムを把握する必要があります。不可能ではありませんが、「aspnet_regiis -pd ...」を実行するよりも確かに困難です。
一方、私はこの6年前の質問に対するより良い答えも探しています...
パスワードはさまざまな方法で回復できるため、ソースコードにパスワードを保存する「最良の方法」はありません。
パスワード文字列を難読化するか暗号化して、単純な表示による漏洩を防止できますが、深刻な保護として扱うことはできません。
暗号化された値としてweb.configファイルに配置できます。それほど難しくはないようです：K scott Allen tutorial http://odetocode.com/blogs/scott/archive/2006/01/08/encrypting-custom-configuration-sections.aspx
他の情報へのリンクを含むScott guのブログ投稿があると思います。 http://weblogs.asp.net/scottgu/archive/2006/01/09/434893.aspx
AESのような強力なもので暗号化しますが、SLaksが暗示しているように、攻撃者はコードをリバースエンジニアリングし、暗号化の方法とキーを決定できます。あなたがしているのは、スクリプトキディと特定レベルの攻撃者を排除するレイヤーを追加することです。本当にそれをうまくやりたい人は、できます。また、プログラムを実行して、送信されるパスワードを監視することもできます。
ソースコードにパスワードを保存しないでください。
これをお読みください： http://en.wikipedia.org/wiki/Security_through_obscurity
良い方法はありません。
できることは、スマートアルゴリズムを使用してパスワードを暗号化することだけです。
経験豊富なリバースエンジニアがそれを破ることができます。
パスワードを本当に必要としている人に対してできることはあまりありません。ただし、これがパブリックアプリ（イントラネット？社内アプリなど）でない場合は、対称暗号化アルゴリズムを使用して単純に暗号化するか、Base 64エンコードなどの操作を行うことができます。また、コード上で難読化ツールを実行して、どこかにパスワードがあることをわかりにくくすることもできます。
別のオプションがありますか？生のSFTPアクセスはちょっと危険です。たぶん、その間に何らかの種類のプロキシサービスを作成して、アプリに必要な特定のアクションのみを許可することができます。コードにそのサービスのパスワードを保存することは、コードにSFTPパスワードを保存するほど危険ではありません。
SLP Code Protector のようなものを使用して、アセンブリのリバースエンジニアリングをブロックできます。それでも、私は他の皆に同意します、それは最高のアイデアではありません。