アカウント名:
パスワード:
送るデーターに関してはフォーマットを開示しなければならないとか、EULAでエンドユーザーの同意を求めるときはそのフォーマットを表示して、同意はその範囲内でのみとするとか。サーバーに送信した内容と同一のデーターをローカルに残すとか。
何らかの規制が必要なのは確かですが、プロダクトアクティベーションやDRMなど、「書式やデータを開示することによって、機能の意味がなくなるもの」もあるので、難しいところですね。
結局のところは「オープンソースこそ至高」になるんでしょうか。
ゆきつくところは非対称鍵暗号による保護なので、実は過程は見えちゃってもいいんですよ
オフラインアクティベーションできること、つまり、別PCか電話を経由してアクティベーションできること、(広義の)チャレンジ・レスポンスファイルは一定範囲で人間が読めるもの。このくらいはできる
チャレンジファイルがたとえばXMLで、(例)が十分小さければ、その程度以上のエントロピーのデータは持ち出せなかったと推認できる
ハンドシェークが1往復で済めば、いうことないんですが。(たとえば、Windows10のSLS2は、何度かの登録処理の後に本認証にかかるようで、1往復ではありません)
> (広義の)チャレンジ・レスポンスファイルは一定範囲で人間が読めるもの。このくらいはできる
で、その中にユーザの機密情報が含まれていないことをどうやって証明するんでしょうか?その中のデータに何が書かれているかを全部公開しない限り、証明できないのでは?
> チャレンジファイルがたとえばXMLで、(例)が十分小さければ、
パスワードやセッションIDであれば、情報のエントロピーなどごく僅か(数バイトから数十バイト程度)ですよね・・
> 数バイトから数十バイト程度
まったくそのとおり。ハードウェア情報のハッシュ集であったとしても、たとえば、1KBもあったらおかしいわけですむやみに大きいデータが送信されていたら、それ俺(最終顧客)の個人情報ですよね、といわれても仕方ありませんそれで実際には、チャレンジ側のヘッダ、バージョン、タイムスタンプなどが必要なわけですけど、そこは見られて困るものではないと。ごく肝心なところだけ暗号化して、他は【見せ】ればいいんです
「まったくそのとおり」って…
「『本来漏れてはいけない』パスワードやユーザーIDだって数バイト~数十バイトなんだから見分けつかねーだろ?」っていうのが元レスだろ
次善の策として開発者側ができることを考えてる一切漏洩しないことを保証せんとするなら、防音遮蔽、電気的接点はフィルタ付きの電源のみとするほかない
なんか最近この手の「突っ込みを受けた後まったく見当違いのレスをする」のを何件かみるな…同じ人なのかな
>送るデーターに関してはフォーマットを開示しなければならないとか
開示されたら、それを信じるの?抜き打ちでデータをデコードしてもらったら、それを信じるの?
そのプログラムには、社外公開用って書いてなかった?
そのアプリを業務で採用するとして、顧客に情報保護の取り組みの詳細を問われたとします通信形式の開示もなく(たとえば、ポート12345に独自形式で通信)、データのデコードもできない(徹頭徹尾暗号化されたデータを64KBほど送信)となると、説明は難しくなるでしょうね
通信に立ち会えるということは、ないよりはましなことなのです
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
規制が必要なんじゃないのかな? (スコア:1)
送るデーターに関してはフォーマットを開示しなければならないとか、
EULAでエンドユーザーの同意を求めるときはそのフォーマットを表示して、同意はその範囲内でのみとするとか。
サーバーに送信した内容と同一のデーターをローカルに残すとか。
Re: (スコア:0)
何らかの規制が必要なのは確かですが、プロダクトアクティベーションやDRMなど、
「書式やデータを開示することによって、機能の意味がなくなるもの」もあるので、
難しいところですね。
結局のところは「オープンソースこそ至高」になるんでしょうか。
Re: (スコア:0)
ゆきつくところは非対称鍵暗号による保護なので、実は過程は見えちゃってもいいんですよ
オフラインアクティベーションできること、つまり、別PCか電話を経由してアクティベーションできること、
(広義の)チャレンジ・レスポンスファイルは一定範囲で人間が読めるもの。このくらいはできる
チャレンジファイルがたとえばXMLで、(例)が十分小さければ、
その程度以上のエントロピーのデータは持ち出せなかったと推認できる
ハンドシェークが1往復で済めば、いうことないんですが。
(たとえば、Windows10のSLS2は、何度かの登録処理の後に本認証にかかるようで、1往復ではありません)
Re: (スコア:0)
> (広義の)チャレンジ・レスポンスファイルは一定範囲で人間が読めるもの。このくらいはできる
で、その中にユーザの機密情報が含まれていないことをどうやって証明するんでしょうか?
その中のデータに何が書かれているかを全部公開しない限り、証明できないのでは?
> チャレンジファイルがたとえばXMLで、(例)が十分小さければ、
パスワードやセッションIDであれば、情報のエントロピーなどごく僅か(数バイトから数十バイト程度)ですよね・・
Re: (スコア:0)
> 数バイトから数十バイト程度
まったくそのとおり。ハードウェア情報のハッシュ集であったとしても、たとえば、1KBもあったらおかしいわけです
むやみに大きいデータが送信されていたら、それ俺(最終顧客)の個人情報ですよね、といわれても仕方ありません
それで実際には、チャレンジ側のヘッダ、バージョン、タイムスタンプなどが必要なわけですけど、
そこは見られて困るものではないと。ごく肝心なところだけ暗号化して、他は【見せ】ればいいんです
Re: (スコア:0)
「まったくそのとおり」って…
「『本来漏れてはいけない』パスワードやユーザーIDだって数バイト~数十バイトなんだから見分けつかねーだろ?」っていうのが元レスだろ
Re: (スコア:0)
次善の策として開発者側ができることを考えてる
一切漏洩しないことを保証せんとするなら、防音遮蔽、電気的接点はフィルタ付きの電源のみとするほかない
Re: (スコア:0)
なんか最近この手の「突っ込みを受けた後まったく見当違いのレスをする」のを何件かみるな…
同じ人なのかな
Re: (スコア:0)
>送るデーターに関してはフォーマットを開示しなければならないとか
開示されたら、それを信じるの?
抜き打ちでデータをデコードしてもらったら、それを信じるの?
そのプログラムには、社外公開用って書いてなかった?
Re: (スコア:0)
そのアプリを業務で採用するとして、顧客に情報保護の取り組みの詳細を問われたとします
通信形式の開示もなく(たとえば、ポート12345に独自形式で通信)、
データのデコードもできない(徹頭徹尾暗号化されたデータを64KBほど送信)となると、
説明は難しくなるでしょうね
通信に立ち会えるということは、ないよりはましなことなのです