アカウント名:
パスワード:
「保存しろ」と言われたら、後で取り出せないといけないと解釈して可逆方式にするよ。「パスワード方式で認証できるようにしろ」なら、認証さえできればいいから、非可逆にするけど。
論文を斜め読みした感じでは,実験では260人のJAVA使いに仕事(JAVA+PostgreSQL)を依頼して,211人に断れられていますつまり,この実験はそもそも8割の人に断られて,残りの2割の人から集めたデータを解析したものです.
断られた理由は返信なし:72名JAVAとかSQLとか判らないという理由で辞退:63 名忙しいから無理:22名などでした(ちゃんと読んでいませんが,ぱっと見では,文章中の人数と表の人数があっていないようでした)
そして残った49名のうち,5名は仕事が完了できなくてクビ,最終的に残った44名が論文のデータになっています
また44名のうちで,最初の納品でパスワードを暗号化してなかった人は,暗号化して再納品を指示していますですので,44名のフリー開発者の納品物は,一応全て暗号化されています.(多分5名は暗号化できなくてクビ扱いです)
ただその暗号化の方法が BASE64 だったり SHAでまちまち (詳しい事は論文の表 2に書いてあります)というのがこの論文の内容です
このような内容ですので,いろんな意味で「フリー開発者に登録フォームを作成させたところ半分以上がパスワードをハッシュ化しなかったという研究結果」というタイトルは不適切な気がします.
個人的には,特に211名つまり8割以上の人に依頼を断られている時点で実験デザインが悪いと思います.意地悪な言い方をすれば- データはサンプルが偏っている- 実験の結果,ハッシュ化しなかったのは 22名だけ.8割以上は調査できなかった.- データの解釈として,普通なら断るような仕事を引き受けた,つまり仕事に困っているエンジニアだからレベルが低いとも言えるという感じで突っ込み可能な内容です.そのまま鵜呑みにするのは危険な論文だと思います.
JAVA使いに依頼してJAVAがわからないという理由で断られたとは一体
(はぁ?1万?何言ってんだこいつ)「あ、Javaわからないんでやめときます」
JavaScript だったとか
PHP使えますオブジェクト指向わかりませんC++書けます(Cのコンパイラでコンパイルできる範囲なら)
たしかに、この価格帯ではその程度の開発者しか受注しない、というのはありそうだなぁと思ったとして、
> そして残った49名のうち,5名は仕事が完了できなくてクビ
ラン○ーズみたいなとこで募ったんだと思うが、この内容で仕事が完了できないってスキルレベル低すぎだろJK…あと、暗号化しろって言われてBASE64にしてくる奴らも恐ろしい。
いや、安いから後回しにして間に合わなかったから首かもしれないしレベルが低いと判断出来るかどうかはわからないでしょう
フリーランスにソフトウェア開発依頼すると断られる研究と題目を変えたほうがよかったような・・・w
「フリーランスに200ユーロで開発依頼をしたら8割断られて残り2割はかなりヤバイ」という研究かな…まぁそうなるよな…という感想
Secure InsecurePrompted100 5 4Prompted200 8 4Non-Prompted100 1 10Non-Prompted200 3 7
「指示を出した人は過半数がハッシュ関数を使用」とはいったものの、それでも21分の8はハッシュ関数を使わなかったのか。指示しなかった評価群の21分の17と比べりゃ遥かにマシとはいえ、これは酷い。。。
MD5もSecureになってるけど、これはええのかな。Salt有無も特に問題とされてないようだ。まぁひどいやつが最悪にひどいからか。
パスワードリセットフォームを用意した開発者は1人もいなかった....(かも)
1万でそこまでやれとか言われてもね
流用可能な出来合いのものを持っているとかでなければ断るよなあ。
安全に保管しろと言われててやってない奴は論外としてもお金をいくら積まれようが指示が無いことまで勝手にやるべきじゃないから、開発者としての腕だの倫理観だのそんなこととは無関係な気がする。
通常の業務であれば真っ先に要件定義の段階で聞く内容だけど、この実験では発注以後の納品までコミュニケーションはたぶんないんでしょ?
発注側は発注時に気をつけろってことを言いたいんだろうか。
CoCo壱なら、カレーにはスプーンがついてくるのは常識であって、個別に注文する必要があるものではない。しかし本格的なカレー店では、もしかしたらスプーンがついてこないかも知れない。# 手で食ってるところに、インド人の店長が申し訳なさそうにスプーンを持って来るまである。
一般的に「××には○○するのは常識であって、個別に注文しなければならないものではない」ってのは往々にしてあるよね。
今回、パスワードに関してはハッシュはセットではなくオプションである、と考える技術者が少なくない事が分かったのは、とても興味深い事だと思う。「そうあるべきである」「いやそれじゃイカンでしょ」と議論するのはこれからだね。
> この実験では発注以後の納品までコミュニケーションはたぶんないんでしょ?違う。論文読め。
> 発注側は発注時に気をつけろってことを言いたいんだろうか。違う。論文読め。
面倒、研究者ならともかく、雑談サイトでそこまで要求されても。
で、どういう結論なのさ。
情報ゼロのこのコメントがなぜプラスモデされるのか。
>正しい。論文読め。こう返せばよかったのかな?
>>発注以後の納品までコミュニケーションはたぶんないんでしょ?>違う。論文読め。
アブストに書いてないようですが。英語を本文全部読めと?主眼はコミュニケーションじゃないようですが。
書いてないことを勝手にやってくれなかったって言う結果に何の意味があるのか分かんないですよね
やりがい搾取したいのかな
「指示されなかったからやらなかったもーん」とか言っても裁判所には通じないみたいだよhttps://security.srad.jp/story/15/01/22/0819244/ [security.srad.jp]
パスワードのハッシュ化を言われないとやらないようなエンジニアは使うなってことじゃね。もしくは世の中その程度のエンジニアであふれかえってると言いたいか。
パスワードを保存する事が要件ならハッシュ化したらパスワードは失われるから問題外
Abstractにはwrite code that stores passwords securelyとあるね。確かにハッシュを保存しただけだとパスワードを保存してない。指示に問題がある?
パスワードのハッシュ化は漏洩や内部関係者の悪用に対するセーフティであって、セキュアな保存とは違うと言われれば違うしなあ英語でも言葉に開発の落とし穴はあるのか
漏れる可能性が高いんですねわかります
報酬が100から200ユーロなのか。つまり1万円から2万円。価格相当のクオリティの気がするんだが。
もう一桁増やしたら結果がどうなるか興味ある。
言語とDBを変えた場合も気になる
その通り。この金額で、やる方がおかしいでしょ。
実際8割の人に断られたらしいし
Cognitoで済ませる
だから、8割の人に断られてるのでしょうね。この価格でも断らなかった残りの2割の調査だから、お値段相当としか言いようがない。
バイト感覚の人に仕事頼んでみたなのかもね本業がプログラマでない人が小遣い稼ぎもできるのが、ネットで仕事頼むサイトを利用するメリットだったりするw
何桁増やしてもハッシュ関数通すかどうかが変わるとも思いませんが
> 特に高度でもないクリエイターに対する報酬は、ユーロ圏でも大した事は無い。って読む記事なのでは?
そんな読み方するのはあなただけですよ
まぁコミュ障であることは否定しないが。
指示されなかったときの「開発時」のデフォルトは暗号化しない方だと思います。なぜなら、暗号化した場合、開発にもデバックにも時間がかかるので。
1,2万円程度なんて、単なる開発のサンプルだと思って、何もしないと思います。
どのみち暗号化そのものは簡単ですし。昔はアルゴリズムから考えたものだ。。
不可逆にしても良いという言質を取るまでは、生パスワードが必要な用件が追加される可能性があるので可逆な形で暗号化すると思います。
それよりも、外部サービスを使うためとかで、それのパスワードを可逆的に保存しなきゃいけない状態の方が面白い結果になりそう。
諦めて平文、とりあえずbase64でなんちゃってで隠す、鍵をサーバーの読めるところに置いて暗号化、鍵はプロセスのメモリーに起動時に読み込ませて、ファイルとしては保存しない、とか付近で色々な結果になるのかな。
すまないパイロットスタディーも
どこにひっかかってるのかよくわからんのだがIT業界では普通の用語です。他にも「押下」とか辞書になくても日常的に使う語がある。
専門用語なので。
平文(ひらぶん)↓暗号化暗号↓復号平文
なんでsaltが固定値なんだろうランダムが普通じゃないのかしら
何か物凄く読みにくいコメントだな…頭に入ってこない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
コミュ障かもしれないが (スコア:5, 興味深い)
「保存しろ」と言われたら、後で取り出せないといけないと解釈して可逆方式にするよ。
「パスワード方式で認証できるようにしろ」なら、認証さえできればいいから、非可逆にするけど。
実験では260人のJAVA使いに仕事を依頼して,211人に断れられている (スコア:5, 参考になる)
論文を斜め読みした感じでは,実験では260人のJAVA使いに仕事(JAVA+PostgreSQL)を依頼して,211人に断れられています
つまり,この実験はそもそも8割の人に断られて,残りの2割の人から集めたデータを解析したものです.
断られた理由は
返信なし:72名
JAVAとかSQLとか判らないという理由で辞退:63 名
忙しいから無理:22名
などでした(ちゃんと読んでいませんが,ぱっと見では,文章中の人数と表の人数があっていないようでした)
そして残った49名のうち,5名は仕事が完了できなくてクビ,最終的に残った44名が論文のデータになっています
また44名のうちで,最初の納品でパスワードを暗号化してなかった人は,暗号化して再納品を指示しています
ですので,44名のフリー開発者の納品物は,一応全て暗号化されています.(多分5名は暗号化できなくてクビ扱いです)
ただその暗号化の方法が BASE64 だったり SHAでまちまち (詳しい事は論文の表 2に書いてあります)
というのがこの論文の内容です
このような内容ですので,いろんな意味で
「フリー開発者に登録フォームを作成させたところ半分以上がパスワードをハッシュ化しなかったという研究結果」
というタイトルは不適切な気がします.
個人的には,特に211名つまり8割以上の人に依頼を断られている時点で実験デザインが悪いと思います.
意地悪な言い方をすれば
- データはサンプルが偏っている
- 実験の結果,ハッシュ化しなかったのは 22名だけ.8割以上は調査できなかった.
- データの解釈として,普通なら断るような仕事を引き受けた,つまり仕事に困っているエンジニアだからレベルが低いとも言える
という感じで突っ込み可能な内容です.そのまま鵜呑みにするのは危険な論文だと思います.
Re:実験では260人のJAVA使いに仕事を依頼して,211人に断れられている (スコア:5, おもしろおかしい)
JAVA使いに依頼してJAVAがわからないという理由で断られたとは一体
Re:実験では260人のJAVA使いに仕事を依頼して,211人に断れられている (スコア:5, おもしろおかしい)
(はぁ?1万?何言ってんだこいつ)
「あ、Javaわからないんでやめときます」
Re:実験では260人のJAVA使いに仕事を依頼して,211人に断れられている (スコア:1)
JavaScript だったとか
Re: (スコア:0)
PHP使えますオブジェクト指向わかりません
C++書けます(Cのコンパイラでコンパイルできる範囲なら)
Re: (スコア:0)
たしかに、この価格帯ではその程度の開発者しか受注しない、というのはありそうだなぁと思ったとして、
> そして残った49名のうち,5名は仕事が完了できなくてクビ
ラン○ーズみたいなとこで募ったんだと思うが、この内容で仕事が完了できないってスキルレベル低すぎだろJK…
あと、暗号化しろって言われてBASE64にしてくる奴らも恐ろしい。
Re: (スコア:0)
いや、安いから後回しにして間に合わなかったから首かもしれないし
レベルが低いと判断出来るかどうかはわからないでしょう
Re: (スコア:0)
フリーランスにソフトウェア開発依頼すると断られる研究
と題目を変えたほうがよかったような・・・w
Re:実験では260人のJAVA使いに仕事を依頼して,211人に断れられている (スコア:1)
「フリーランスに200ユーロで開発依頼をしたら8割断られて残り2割はかなりヤバイ」という研究かな…
まぁそうなるよな…という感想
各分類ごとの内訳も載せないと意味ないのでは? (スコア:3, 参考になる)
Secure Insecure
Prompted100 5 4
Prompted200 8 4
Non-Prompted100 1 10
Non-Prompted200 3 7
Re: (スコア:0)
「指示を出した人は過半数がハッシュ関数を使用」とはいったものの、それでも21分の8はハッシュ関数を使わなかったのか。
指示しなかった評価群の21分の17と比べりゃ遥かにマシとはいえ、これは酷い。。。
Re: (スコア:0)
MD5もSecureになってるけど、これはええのかな。
Salt有無も特に問題とされてないようだ。
まぁひどいやつが最悪にひどいからか。
それよりも... (スコア:3, 興味深い)
実際、自分は 22 歳よりも 68 歳の方が遥かに近い。
そして、 (スコア:1)
パスワードリセットフォームを用意した開発者は1人もいなかった....(かも)
Re:そして、 (スコア:1)
1万でそこまでやれとか言われてもね
Re: (スコア:0)
流用可能な出来合いのものを持っているとかでなければ断るよなあ。
この結果をどう受け止めるべきなの? (スコア:0, 荒らし)
安全に保管しろと言われててやってない奴は論外としても
お金をいくら積まれようが指示が無いことまで勝手にやるべきじゃないから、
開発者としての腕だの倫理観だのそんなこととは無関係な気がする。
通常の業務であれば真っ先に要件定義の段階で聞く内容だけど、
この実験では発注以後の納品までコミュニケーションはたぶんないんでしょ?
発注側は発注時に気をつけろってことを言いたいんだろうか。
Re:この結果をどう受け止めるべきなの? (スコア:2, 参考になる)
CoCo壱なら、カレーにはスプーンがついてくるのは常識であって、個別に注文する必要があるものではない。
しかし本格的なカレー店では、もしかしたらスプーンがついてこないかも知れない。
# 手で食ってるところに、インド人の店長が申し訳なさそうにスプーンを持って来るまである。
一般的に
「××には○○するのは常識であって、個別に注文しなければならないものではない」
ってのは往々にしてあるよね。
今回、パスワードに関してはハッシュはセットではなくオプションである、と考える技術者が
少なくない事が分かったのは、とても興味深い事だと思う。
「そうあるべきである」「いやそれじゃイカンでしょ」と議論するのはこれからだね。
Re: (スコア:0, 参考になる)
> この実験では発注以後の納品までコミュニケーションはたぶんないんでしょ?
違う。論文読め。
> 発注側は発注時に気をつけろってことを言いたいんだろうか。
違う。論文読め。
Re: (スコア:0, フレームのもと)
面倒、
研究者ならともかく、雑談サイトでそこまで要求されても。
Re: (スコア:0)
で、どういう結論なのさ。
Re: (スコア:0)
情報ゼロのこのコメントがなぜプラスモデされるのか。
Re: (スコア:0)
>正しい。論文読め。
こう返せばよかったのかな?
Re: (スコア:0)
>>発注以後の納品までコミュニケーションはたぶんないんでしょ?
>違う。論文読め。
アブストに書いてないようですが。英語を本文全部読めと?
主眼はコミュニケーションじゃないようですが。
Re: (スコア:0)
書いてないことを勝手にやってくれなかったって言う結果に何の意味があるのか分かんないですよね
やりがい搾取したいのかな
Re:この結果をどう受け止めるべきなの? (スコア:1)
「指示されなかったからやらなかったもーん」とか言っても裁判所には通じないみたいだよ
https://security.srad.jp/story/15/01/22/0819244/ [security.srad.jp]
Re: (スコア:0)
パスワードのハッシュ化を言われないとやらないようなエンジニアは使うなってことじゃね。
もしくは世の中その程度のエンジニアであふれかえってると言いたいか。
Re: (スコア:0)
パスワードを保存する事が要件ならハッシュ化したらパスワードは失われるから問題外
Re: (スコア:0)
Abstractにはwrite code that stores passwords securelyとあるね。
確かにハッシュを保存しただけだとパスワードを保存してない。指示に問題がある?
Re:この結果をどう受け止めるべきなの? (スコア:1)
パスワードのハッシュ化は漏洩や内部関係者の悪用に対するセーフティであって、セキュアな保存とは違うと言われれば違うしなあ
英語でも言葉に開発の落とし穴はあるのか
Re: (スコア:0)
漏れる可能性が高いんですね
わかります
報酬額 (スコア:0)
報酬が100から200ユーロなのか。つまり1万円から2万円。価格相当のクオリティの気がするんだが。
もう一桁増やしたら結果がどうなるか興味ある。
Re:報酬額 (スコア:1)
言語とDBを変えた場合も気になる
Re: (スコア:0)
その通り。この金額で、やる方がおかしいでしょ。
Re: (スコア:0)
実際8割の人に断られたらしいし
Re: (スコア:0)
Cognitoで済ませる
Re: (スコア:0)
だから、8割の人に断られてるのでしょうね。
この価格でも断らなかった残りの2割の調査だから、お値段相当としか言いようがない。
Re: (スコア:0)
バイト感覚の人に仕事頼んでみたなのかもね
本業がプログラマでない人が小遣い稼ぎもできるのが、ネットで仕事頼むサイトを利用するメリットだったりするw
Re: (スコア:0)
何桁増やしてもハッシュ関数通すかどうかが変わるとも思いませんが
Re: (スコア:0)
> 特に高度でもないクリエイターに対する報酬は、ユーロ圏でも大した事は無い。って読む記事なのでは?
そんな読み方するのはあなただけですよ
私も指示されないとやらない気がする。 (スコア:0)
まぁコミュ障であることは否定しないが。
指示されなかったときの「開発時」のデフォルトは暗号化しない方だと思います。
なぜなら、暗号化した場合、開発にもデバックにも時間がかかるので。
1,2万円程度なんて、単なる開発のサンプルだと思って、何もしないと思います。
どのみち暗号化そのものは簡単ですし。昔はアルゴリズムから考えたものだ。。
顧客の同意が取れるまではとりあえず安全な方向に倒すかな (スコア:0)
不可逆にしても良いという言質を取るまでは、生パスワードが必要な用件が追加される可能性があるので可逆な形で暗号化すると思います。
パスワードを可逆的に保存しなきゃいけない場合 (スコア:0)
それよりも、外部サービスを使うためとかで、それのパスワードを可逆的に保存しなきゃいけない状態の方が面白い結果になりそう。
諦めて平文、とりあえずbase64でなんちゃってで隠す、鍵をサーバーの読めるところに置いて暗号化、鍵はプロセスのメモリーに起動時に読み込ませて、ファイルとしては保存しない、とか付近で色々な結果になるのかな。
Re: (スコア:0)
すまないパイロットスタディーも
Re: (スコア:0)
どこにひっかかってるのかよくわからんのだが
IT業界では普通の用語です。
他にも「押下」とか辞書になくても日常的に使う語がある。
Re: (スコア:0)
>バカなの?
と強い言葉を使っていますが、私のような門外漢だとピンとこないもので。
Re: (スコア:0)
専門用語なので。
平文(ひらぶん)
↓暗号化
暗号
↓復号
平文
Re:言語別ログイン機能パスワード処理方針 (スコア:2)
なんでsaltが固定値なんだろう
ランダムが普通じゃないのかしら
Re:見てみてこれ ひどいことになってるでしょう (スコア:2)
何か物凄く読みにくいコメントだな…
頭に入ってこない