2009-05-20 9 views
1

私は、顧客が会社の詳細を更新できるように小さなWebアプリケーションを構築しています。顧客は現在ログイン/パスワードを持っていないため、登録を検証したくないので、ウェブサイトにログインするために自動的に生成されたパスワード/キーを与えたいと考えています。intから短い文字列への双方向の暗号化

私たちは、顧客IDを暗号化して顧客に渡し、その鍵をウェブアプリケーションに入力できるようにして、鍵を自分のIDに復号化できるようにします。

約10Kの顧客がいて、すべてが電子メールを持っているわけではないため、URLとコードの文字を受け取るものもあります。つまり、顧客はコードを入力する必要があるため、コードは8文字(好ましくは6文字)を超えることはできません。

ここでは、空のテンプレートです:

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 

namespace ConsoleApplication1 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      int passwordLength = 6; 
      int customerId = 12345; 
      string encrypted = Crypter.Encrypt(customerId, "secretKey", passwordLength); 
      if (customerId == Crypter.Decrypt(encrypted, "secretKey")) 
      { 
       Console.WriteLine("It worked! Well done!"); 
      } 
     } 

    } 

    public static class Crypter 
    { 
     public static string Encrypt(int input, string key, int passwordLength) 
     { 
      string encryptedString = ""; 
      //do encrypt stuffz here 

      return encryptedString; 
     } 
     public static int Decrypt(string encryoted, string key) 
     { 
      int decrypted = 0; 
      //do decrypt stuffz here 

      return decrypted; 
     } 
    } 
} 

=>誰もがこれを行う方法についての詳細を私にリンクできますか?

私は "plz send me teh codez"を探しているわけではありませんが、誰かがすでにこのようなことをしている場合は、気軽に共有してください。

ありがとうございます。

答えて

4

まず、あなたのアイデアが非常に優れているかどうかはわかりません。しかし、それを覚えておくために、私は本当に何かを暗号化/復号化する必要があるかどうかはわかりません。

あなたが言っていることは、内部顧客IDを取得して、別のID(お客様の場合、内部顧客IDの暗号化バージョン)に変換するということです。なぜなら、内部顧客ID(データベースに保存してプライマリキーとして使用するID)と外部顧客ID(別の8桁のユニークキー)を作成するだけではいかがですか。両方をデータベースに格納し、後でそれに基づいて参照する「ログイン」を実行します。

私はあなたと同じように考えています。誰かがあなたの6桁または8桁のキーを推測するのを止めますか?誰かがあなたのサイトへの攻撃を実行し、誰かのキーを推測するのに長い時間がかからないのは、わずか6〜8桁の文字セットの暗号化されたIDであるかどうかにかかわらずです。これらのキーを正確に6桁または8桁にフォーマットするという事実は、攻撃者の仕事を容易にします。

私はこの8桁のキーを送信して、あなたがすでに知っている情報(氏名、電子メールアドレス、会社名など)を入力してから、自分の選択したユーザーID /ログイン。

+0

うーん、私たちは考えていないいくつかの事.. これは良い解決策のようなソーダ。私はちょうどデータベーステーブルを除いてIDとの関係を決して持っていないランダムな文字列を作成することができます。非常に安全で、このプロジェクトでは実装するのに問題はありません。ありがとう! –

+0

何らかの理由で顧客IDを変更する必要がある場合(新しいストレージバックエンドへの移行)、「ログイントークン」を変更する必要はありません。 –

1

私はあなたの意図をここではっきりと理解していません。 UUIDなどを生成して、それをユーザーのコードとして使用することはできませんか?データベース内のユーザーIDの横に格納するだけで済みます。

一意性を保証する代わりに、2つの別々の入力に基づいてN-charコードを生成することができます。つまり、8文字のうち5文字はランダムに生成でき、残りの3文字は顧客IDに基づいています。

+0

提案してくれてありがとう –

8

あなたの秘密のコードはユーザーIDに基づいてはなりません。代わりに、顧客ごとにランダムな6文字の文字列を生成し、データベースに格納します。実際のアルゴリズムを見つけるのは脆弱ではありません。

+3

母音を削除するか、ランダムな文字列(あるいはその両方)をプレビューし、あなたが自分のパスワードとして彼らに厄介な単語が割り当てられているため、あなたがどんな顧客を失わないことを確認します。おそらく、あなたはまた、彼らがURLを介して検証した後、彼らがID /パスワードを選択させるでしょう - そうでなければ、非常にユーザーフレンドリーです。 – tvanfosson

+0

@tvanfosson:うわー、それは決して考えなかった! –

+0

提案していただきありがとうございます。 –

0

私は、あなたのデータベースの暗号化された文字列を基にしないと言っている別のポスターに同意します。ユニークなランダムな文字列を生成してデータベースに格納するほうがはるかに簡単です。

ただし、ユーザーIDを使用する必要がある場合は、次の名前空間を参照することをおすすめします。

System.Security.Cryptography

関連する問題