マルチレスや、複数質問のある発言、特に必要のない部分に関しては分割や削除してある場合があります。これも独断と偏見により行わせていただきました。ご理解よろしくお願いします。

また、スレッドの内容へではなく、細かい点への反論などをトーク広場に持ち出すことはご遠慮ください。

基本的に訂正は受け付けませんが、削除の仕方などに間違いがあればトーク広場へ書き込むか、もしくはdream@tech.millto.netまでメールお願いいたします。

こんにちは。ニフティのＳＷＩＮＦＯではお世話になりました　鈴木　大三　です。
以前、ユーザー個別パスワードの自動生成システムについて書き込ませていただきました。

改めてお尋ねしたいのですが、パスワードの流出に対して、どのような防御策を用意して
いるのでしょうか？差し障りのない程度でいいので、工夫をされている方がいらっしゃれ
ば、お教え願えませんでしょうか？

下の発言にレスがつかないということは、特にパスワードの不正流出に対する工夫は
していない、ということなのかナ？

じゃあ、ちょっと聞き方を変えましょう。
固定キーで大丈夫だと思ってるんですか？

これなら Yes or No で答えられるでしょ。

簡単に言うと固定キーも個別キーも同じですね。
流出してしまえ同じですね。単に誰が流したか分かるということだけで
安全とは言えませんが、パスワードを１つのファイルとして渡せばいいと思いますが、
これもこのファイルをアップロードされたら終わりだし、分かりづらいという欠点もありますね。
ちょっと方法を考え中なのですが、機種やＷｉｎｄｏｗｓの独特なコードでそのコンピュータしか
そのパスワードは利用できないようにするという方法が確実では無いかと思います。
または個人情報とか、電話番号とパスワードを組み合わせるという手もあります。
ただあまりに単純だとパターンを解析されてしまう恐れもありますけど

Ksc さん
＞簡単に言うと固定キーも個別キーも同じですね。
ちょっと確認したいのですが、ここで言う「個別キー」は、「半固定キー」の
ことですよね。つまり、一見すると個々のキーが違うようでも、実は誰にでも
使えてしまうような。

従来の固定キーや半固定キーのどこが問題なのか、それは、「１つのキーが
複数のユーザーにも使えてしまう」点にあると思うんです。もし「１つのキー
が１人のユーザーにしか使えない」ものだったら、そもそも流出する意味すら
なくなるでしょう。

Ksc さんの発言の中では、そのようなキーを作るのに個人情報を盛り込めば
いい、とありますが、それだと確かに「危険」です。でも、そんな個人情報を
利用しなくても、「そのユーザーにしか使えないキー」は簡単にできてしまう
んです。しかも、人間業ではおそらく解析できないようなキーを、です。

これはちょっと他のみなさんにも考えてもらおうかナ。
とは言っても、ＳＷＩＮＦＯでさんざん言ってきたことなんだけど(^^;)

>ちょっと確認したいのですが、ここで言う「個別キー」は、「半固定キー」の
>ことですよね。つまり、一見すると個々のキーが違うようでも、実は誰にでも
>使えてしまうような。
私が言ったのは、
固定キー：１つのソフトに１つのパスワード
個別キー：１つのソフトに沢山のパスワード
ってなことです。半固定キーと同じだと思います。

>利用しなくても、「そのユーザーにしか使えないキー」は簡単にできてしまう
>んです。しかも、人間業ではおそらく解析できないようなキーを、です。
これはどうゆうことですか？過去ログとかにあったらゴメンナサイ
ただあるコンピューターに対して１つのパスワードの場合はそのコンピューター情報を
こっちに送信しなくてはなりませんね。その作業がちょっと困難だと思うのですが、（＾＾；

Ksc さん
＞ただあるコンピューターに対して１つのパスワードの場合はそのコンピューター
＞情報をこっちに送信しなくてはなりませんね。その作業がちょっと困難だと思う
＞のですが、（＾＾；
ちょっと発想を変えてみてほしいのですが、「１人のユーザーにしか使えない鍵」
を作るためには、「１人ひとりに違う鍵穴」を用意するべきですよね。その「鍵穴」
の形を、鍵を作る人（＝シェアウェア作者）に教えて、それではじめて「鍵」を
作ることができます。

うーん、なんか抽象的だな(^^;)。
なんか５００文字の制限があるようなので、具体的かつ５００文字に収まる文を
考えておきます。

　固定キーでは、キー（文字コード等）自体が流出するでせう。
　個別キーでは、アルゴリズムが流布したり、そのアルゴリズムを用いて個
別キーを作成するソフトが出てくるかと。

>ちょっと発想を変えてみてほしいのですが、「１人のユーザーにしか使えない鍵」
>を作るためには、「１人ひとりに違う鍵穴」を用意するべきですよね。その「鍵穴」
>の形を、鍵を作る人（＝シェアウェア作者）に教えて、それではじめて「鍵」を
>作ることができます。

そうですね。問題は「鍵穴」をどう作者に教えるかではないでしょうか？

>　個別キーでは、アルゴリズムが流布したり、そのアルゴリズムを用いて個
>別キーを作成するソフトが出てくるかと。

イタチゴッコですからね。めちゃくちゃ複雑なアルゴリズムにするしかないでしょう。

ユーザー特有の「鍵穴」と、それを開くためのパスワードを作るために、以下
のような手順を考えてみました。

（１）
そのソフトをはじめて起動するときに、全くランダムな８ケタの数字列を設定、
保存する（「鍵穴」の設定）。

（２）
ユーザーは、その数字列を作者まで送る。

（３）
作者はその数字列を基に、対応したパスワードを作り、ユーザーに送る。

（４）
ユーザーがそのパスワードを入力することで、制限解除となる。

具体的な例を次の発言で。

例えば、Ａさんがソフトをはじめて起動して、そのソフトウェア・コピーに
「33452395」という数字列が設定されたとします。Ａさんはそれを作者ま
で送り、「62956-93825」というパスワードをもらいました。Ａさんはこ
れを入力することで、制限を解除することができます。

一方、Ｂさんのソフトウェア・コピーには、「08495384」という数字列が
設定されました。このコピーに、Ａさんが得た「62956-93825」というパ
スワードを入力するとどうなるか？これは、誤ったパスワードとして認識され
ます。なぜなら、「鍵穴」として設定された数字列が異なるからです。

こうすることにより、「その人にしか使えないパスワード」を作ることが可能
です。

さらに一歩踏み込んで、「鍵穴」として設定する数字列に、「使用環境に関す
るデータ」を盛り込んでみたらどうでしょうか？どの程度まで調べることがで
きるかはちょっとわかりませんが、こうすることで「セーブファイルをそのま
まやりとりする」ことにもある程度の歯止めが効くと思います。

それで、地道にメール交換でパスワードを作成する作業を行ってもいいのです
が、これだと「ユーザーからの連絡を待たなければならない」ので、トラブル
が少なからず生じるかもしれません。そこで、この作業の部分をＣＧＩにして
みました。これなら、作者が送金を確認した時点でユーザーに案内を送れば、
あとはユーザーに任せておけます。

こんな感じの流れなのですが、なんとなくわかってもらえましたでしょうか？
わからないところや疑問があれば、なんなりと言ってください。

＞個別キーでは、アルゴリズムが流布したり、そのアルゴリズムを用いて個別
＞キーを作成するソフトが出てくるかと。
まあ絶対に解読されないとは言い切れないのですが、とりあえず５つの例を
載せるので、ちょっと考えてみてください。左側が「鍵穴」で、右側がいずれ
も同じアルゴリズムで作られたパスワードです。

90448345 ・・・ 21296-57768
59635843 ・・・ 48045-07878
21145885 ・・・ 48640-37655
00000001 ・・・ 26246-16065
98724532 ・・・ 68625-51560

このアルゴリズムは当然ソフトウェアごとに異なります。

最終的には、「プログラムを解析されない限りパスワードの流出、もしくは
作成ができない」というレベルまで持っていきたいのです。確かにプログラム
解析をされてしまったらそれまで、ということになりますが、それにはかなり
の知識や機材を必要とし、そうそう簡単にはできないはず。口コミによる流出
を押さえることにより、今の状態よりは良くなると思います。

＞鈴木　大三さん

　ちと気になったのはここ、
｜（１）
｜そのソフトをはじめて起動するときに、全くランダムな８ケタの数字列を
｜設定、保存する（「鍵穴」の設定）。

　利用者がパソコンを新しくしたり、何らかの事情で再導入をしなくてはな
らなくなった場合、最初に手に入れた「キー」が使えなくなります。
　解決案としては…昔は機種コードがあったんだけどねぇ、今は手組みだし、
利用できる個別コードはあるんだろうか？　そういう情報も収集しないとい
けないし、将来はどうなるかわからない。

＃　窓95の場合、起動時のパスワードを利用するという手もあるけど…パス
＃ワードを変更した際の対処がややこしく。

＃500文字以上は登録できんのか(T-T。

　現在主流になっているコンパイラの特性はあまりよく知らないのですが、
リバースエンジニアリング（プログラムの解析）への対処はどの程度行われ
ているのでしょうか。…とはいいつつ、実行速度の面から考えて暗号化はさ
れてないだろうなぁ…（どのみち、最終的にはＣＰＵに展開されるし）。
　作成コードやキーを見なくても、可能性だけを言えばプログラムから解析
可能です。
　あとは、いらんことする人の技術力と、その行為による収益との兼ね合い
ですな。悲観論で申し訳ない。

これは私も考えたのですが、

＞（１）
＞そのソフトをはじめて起動するときに、全くランダムな８ケタの数字列を設定、
＞保存する（「鍵穴」の設定）。

この時点でみんなが 00000000 にした場合は同じパスワードが出るんですよね。
そうなるとやっぱし広がってしまうのかな？と心配しています。
口コミで「最初は 00000000 でパスワードは xxxxxx ね」ってことになると思うのですが、

＞さらに一歩踏み込んで、「鍵穴」として設定する数字列に、「使用環境に関す
＞るデータ」を盛り込んでみたらどうでしょうか？どの程度まで調べることがで
＞きるかはちょっとわかりませんが、こうすることで「セーブファイルをそのま
＞まやりとりする」ことにもある程度の歯止めが効くと思います。

いまちょっと調べているんですけど、（Windows９５で）機種別コードみたいのって
ないのかな？

てえす　さん
＞利用者がパソコンを新しくしたり、何らかの事情で再導入をしなくてはならな
＞くなった場合、最初に手に入れた「キー」が使えなくなります。
これは作者にまた問い合わせればいいだけ、だと思います。

＞現在主流になっているコンパイラの特性はあまりよく知らないのですが、リバ
＞ースエンジニアリング（プログラムの解析）への対処はどの程度行われている
＞のでしょうか。
確かに解析されてしまうと困るのですが、これを解決するにはマイクロソフトと
かメトロワークスみたいなところが本腰を入れて取り組むしかないでしょう。し
かし、今まで出回っている全てのパスワードが、解析によって得られたものなの
でしょうか？決してそうではないと思います。解析ではない方法、つまり「口コ
ミ」によって流れてしまったのがほとんどでしょう。まずはこれをつぶせないか、
というのが、現在紹介している方法の原点です。

Ksc さん
＞この時点でみんなが 00000000 にした場合は同じパスワードが出るんですよね。
ええっ？？
いや、この数字列を決めるのはユーザーではなく、プログラムの中で勝手にラ
ンダムに決まるんです。だから、同じ数字列になる可能性は１億分の１になる
はずです。さらにこの数字列を決める段階で実行環境に関する情報も盛り込め
ば、厳密さが増してくると思います。

実行環境に関する情報は、これはマックの話なのですが、一連の Gestalt 関数
でいろいろと調べることができたはず。そもそも Win でもマックでも、機種情
報を表示する機能があるんだから、そのための関数が用意されていてもいいん
じゃないでしょうか？

＞＞この時点でみんなが 00000000 にした場合は同じパスワードが出るんですよね。
＞ええっ？？
＞いや、この数字列を決めるのはユーザーではなく、プログラムの中で勝手にラ
＞ンダムに決まるんです。だから、同じ数字列になる可能性は１億分の１になる
＞はずです。さらにこの数字列を決める段階で実行環境に関する情報も盛り込め
＞ば、厳密さが増してくると思います。
なるほど、それなら安心ですね。
それにあわせてCGIでも同じIDを受理しないという機能を付けたらどうかな？

なかなかいい方法ですが完全には防げませんね。

「OSを再インストールしたのでパスワードを教えて下さい。
また会社のパソコンと自分のノートパソコンにも
ソフトをインストールしましたので教えて下さい。
以下の3つの鍵穴がでました。
11111111
22222222
33333333
」

実はこの話はウソで友達のパソコン3台でした。
1ラインセンスで4ライセンス分とられたことになります。
こんなことをすべての人がするとは思えないので
口こみを防ぐことはできると思います。

K-KATSU さん
＞実はこの話はウソで友達のパソコン3台でした。1ラインセンスで
＞4ライセンス分とられたことになります。
うーん、これはしょうがないですね。まあ今までの方法では、１ライセンスで、
作者の知らないところで何十、何百ともしれない数の人間に伝わってしまって
いたのですから、それよりはマシでしょう。

Ksc さん
＞それにあわせてCGIでも同じIDを受理しないという機能を付けたらどうかな？
その案もバッチリです。オン書きだとちょっとつらいので、少しまとめてから
紹介します。

＞鈴木　大三さん
｜　これは作者にまた問い合わせればいいだけ、だと思います。

　パソコン環境を変えた際の再問い合わせですが、意外と利用者にとっては
「また」が面倒だったりします。あ、私が面倒くさがりなだけか(^^;。

　ん？　それ以前に、送金した人としていない人の区別を、作者はどうやっ
て知るのだろう…。
　送金システムを利用した際に発行される何らかのコードをソフトに入力、
パソ環境によって変換されたコードを作者に送ることでキーを手に入れる…。
この過程の中でソフトが「送金した」を認識する証明は「送金システムを利
用した際に発行される何らかのコード」ですが、認識として信頼できるコー
ドでしょうか？

＃考えるのが面倒になってきた(^^;;;…ので、質問にする(笑)。

｜　解析ではない方法、つまり「口コミ」によって流れてしまったのがほと
｜んどでしょう。まずはこれをつぶせないか、というのが、現在紹介してい
｜る方法の原点です。

　キー流出は防げますが、新たなるアルゴリズムの流出が主流になるでしょ
う。けれども、単純な情報流出ではなく、ソフトウェア的な何らかの介在が
必要になので、指摘（摘発）などが楽にはなると思います。
　つまり、コードを生成するサイトやソフトを、経済的損害を招く明確な場
所や物として、たんなる情報と区別できる。あとは財産権の侵害として民事
的に対処するか、ネットワーク上で流通するソフトが物として認知されれば、
不当競争防止法で対処できるようになると考えるわけで。

＃　電子マネーが当然となって、作品の購入とかが頻繁になれば、それなり
＃に法整備が行われると予測しています。

　ただ、実施するとなれば、ソフト毎にキーの作り方が違うとユーザーが混
乱するので「手順」の統一が必要でしょうし、個人的には電子マネー化の際
のＩＤが巧く使えないかなと画策しとります。

「鍵穴」からそれに見合う「鍵」を作るためのＣＧＩの仕様を、こうまとめて
みました。

最初に、ソフトウェア・コピーの方で「鍵穴」である８ケタの数字を用意しま
す（作り方は自由）。ユーザーはこの８ケタの数字を控えておいて、ＣＧＩの
あるページにアクセスします。ここでユーザーは、「鍵穴」の数字列と名前、
メールアドレスを入力します。すると、特定のアルゴリズムに従って「鍵」が
作成されます。ただし、ここで「鍵」が作成できるのは、作者があらかじめ登
録しておいたメールアドレスを持つ者だけで、登録していない場合は作成でき
ません。「鍵」を作成したら、それをメールの形でユーザーと作者に伝えます。
これでユーザーは、「鍵穴」に対応した「鍵」を得たことになります。

作者が登録するメールアドレスは、送金代行業者からの通達によって知ること
ができますよね。

こんな感じなのですが、なんとなく思い浮かべられますか？

＞す（作り方は自由）。ユーザーはこの８ケタの数字を控えておいて、ＣＧＩの
＞あるページにアクセスします。ここでユーザーは、「鍵穴」の数字列と名前、

この鍵穴を書き込む手間は省けると思いますよ。
例えば http://www.xxx.co.jp/cginame.cgi?123456
にすれば 123456 をGET（Perlなら)で取得できると思います。
もちろんこの場合はソフトからページを呼び出す必要がありますが、
私はこの方法でアンケートを取っています。

だいたい今までの発言で、「１人のユーザーのためのパスワード」というのが
ご理解いただけましたでしょうか？わからない点があったら何でも言ってくだ
さい。

で、そろそろ本題に入ろうと思うのですが、今までに紹介したシステムの中で
一番のネックとなっているのは、ＣＧＩの部分でしょう。しかし、これはもう
すでに僕が用意し、実際に自分のソフトで試験運用しています。このＣＧＩを、
みなさんにも使ってもらいたいのです。

実際に作者側でプログラムの中で用意しなければならないことは、
・任意の８ケタの数字列（鍵穴）を設定、保存する。
・「鍵穴」から「鍵」を作るためのルーチンを考える。
・入力された「鍵」が正しいかどうかを判断する。
これだけです。ＣＧＩの知識は全く必要ありません。（次に続く）

かつてフリーウェアがシェアウェアに、シェアウェアがキーウェアに変わった
ように、現在の「１対多の固定キー」から「１対１の特有キー」に変わらなけ
ればならないと思うんです。なぜなら、作者とユーザー以外に、「固定キー」
の性質を利用して利益を得ている第三者がいるから（送金代行業者は除く）。
オンラインソフトの売買を通じて利益を得ていいのは、そのソフトを作った作
者と、そのソフトを使うユーザーのみのはず。「ホームページのアクセスを増
やす」なんていう些細なことでも、第三者が何らかの利益を得ることは全くお
かしな話です。特にネット社会では「匿名性」が強いため、口で言ったって通
じることはありません。そこで、こちらとしても何らかの具体的な対策を講じ
る必要があります。その一環として、今までに紹介してきた「ユーザー特有の
パスワードを作るシステム」があります。もちろんそれにどの程度の効果があ
るのかはわかりませんが、少なくとも今の「固定キー」よりは、具体的であり
説得力のある方法だと思います。もし興味を持たれましたら、ぜひご一報くだ
さい。

　鈴木さんこんにちは。以前より鈴木さんがご提案＆試行されているＷｅｂサイト
を利用した個別パスワード発行システムを興味深く見せて戴いております。

　シェアウェアにおけるパスワードに関しましては、その必要性もふくめて多様な
考え方と方式が存在するのが当然であり、また望ましい姿だと考えます。ここで、
鈴木さんより画期的な方式が提唱されたということは、多くの作者にとっては選択
肢が増えたという意味で非常にありがたいことだと思います。

＝次の書き込みに続く＝

＝下の書き込みから続く＝

　鈴木さんが提唱されているシステムを、他の作者の皆さんにＰＲされるにあたり
ましては、できれば今後の鈴木さんの方向性的なものを表明されておいた方が良い
のではないかと思います。

　具体的には、将来にわたり無償でパスワード発行サービスを提供する予定なのか、
ビジネスに結び付けるおつもりなのか。また、現在サービスを提供しているＵＲＬ
が永続的に使えるのかというあたりは、多くの方にとって一番気になるところでは
ないかと思います。もちろん、不可抗力的なものは仕方ないと思いますが、この辺
を整理した形で表明されますと、皆さんも一歩踏み出しやすくなるのではないかと
思います。

nabe さん
＞無償でパスワード発行サービスを提供する予定なのか、ビジネスに結び付け
＞るおつもりなのか。
将来的にはビジネスに結びつけたいと思っています。とは言うものの、ある程
度認知されるまではボランタリーですけどね。お金だって何万もとるわけでは
なく、シェアウェアの代金程度を要求するくらいです。なぜお金を取るのかと
言うと、「ただより高いものはない」から。お金のやりとりによって、こちら
にも「責任」が生じるでしょうし、使う側も特別な意識が芽生えてくると思い
ます。いいかげんな人には使ってもらいたくない、と言うべきでしょうか。

＞現在サービスを提供しているＵＲＬが永続的に使えるのかというあたり
今のところは「永続的に使える」と答えるしかないでしょう。まあ変更になっ
たところで、このシステムを採用しているソフトをアップグレードしなければ
ならない、ということはありません。

こんな感じですが、どうですか？

　鈴木さん、早速のご回答ありがとうございました。

　将来的に有料サービスとされるご予定ということでしたら、具体的な料金体系や
それまでに無料でサービスして戴いていた作品に対する処置などを明確にして戴け
ると、皆さんも安心されるのではないでしょうか？

　この様なシステムは一度使ってしまうと、『有料になったからやっぱりやめた』
というわけにはなかなか行きませんから、その辺がはっきりしないために二の足を
踏んでいる方もいらっしゃるのでは無いかという気がします。

　折角の斬新なアイデアですので、皆さんが試してみやすくなれは良いと思い、口
出しをさせて戴きました。お気に触りましたら申しわけありません。

nabe さん
＞将来的に有料サービスとされるご予定ということでしたら、具体的な料金体
＞系やそれまでに無料でサービスして戴いていた作品に対する処置などを明確
＞にして戴けると、皆さんも安心されるのではないでしょうか？
なんだか話が具体的になってきて、ゾクゾクしますね。
うーん、「ある期間は無料で、それ以降は有料」というと、けっこう混乱する
かもしれませんね。それなら、シェアウェアの概念と同じく、「試用期間の長
短」で区別しましょう。最初のうちはいろいろとトラブルがあるかもしれない
ので試用期間は長く、軌道に乗ってきたら徐々に短くしていけばいいでしょう。
試用期間の中で料金を払っていただければ、それでＯＫ。使う価値がないと
思ったら試用をやめて、ソフトのほうの修正をすればいいのです。
料金は、売ろうとしているシェアウェア１本分のシェアフィー。高いか安いか
は、その人次第です。

と、話が具体的になっていますが、誰かノッてくれないなかあ。

このアイディア自体は使われるでしょうが、残念ながらそれは鈴木さんに対して、
依頼されるのではなく、シェアウェア送金業者が代行でやるのではないでしょうか？
理由：失礼ながら「個人より」「企業」の方が信頼感がある。
実運用上、1個所で手続きしたほうがらくなので、いずれ送金業者が乗り出す。
（当初は、鈴木さんへの依頼はあるでしょうが）

なお、このアイディア自体は既にあるものです。
シェアウェア用ではありませんが、ユーザー登録用のコード
を単純なシリアルとせず、インストール時間とインストール本数を
暗号化した入れたことがあります。
それを複雑化し、機能制限解除キーとして使うということです。

話の腰を折るようですみませんが．．．

本来であれば、機能制限解除キーなどの仕組み（固定かどうかは別にして）を
がなくても払うのが正しいと思います。
残念ながら以前の書込みを拝見しますと、「ダウンロードの１％未満しか払わない。」
様ですから、なんらかの手段は必要なのかもしれません。
会員の方でシュアウェアだけで生活できる人がいるかどうかわかりませんが、
「シェアウェアで家を建てる」人が出るべきです。（ソフトウェア産業の発展のためにも）
パッケージソフトがほとんどノンプロテクトとなるのに、シュアウェアがキー強化と
いうのは気になるのですが、それにより、送金率が上がるのであれば仕方ないと思います。

PS. みなさんはシェアウェアでの収入はどれくらいあるのでしょうか？
それで生活できるのであれば、今の仕事（下請けプログラマ）はやめるのですが。