例えば、ダレノガレ明美みたいな派手目の女子がRoastMeすると"Your vagina password is PASSWORD"とか、アンガールズ山根みたいな男子がRoastMeすると"Jesus Christ. There’s not a dominant gene in his entire body."みたいな辛辣なコメがばんばんつく。

そのぶん自治ルールもしっかりしていて、違反の投稿はRefuseされる。例えば、投稿した写真の人物が「r/RoastMe」という紙を持っていない場合は本人の写真じゃない可能性があるのでRefuse。

自治ルールがしっかりしてるとはいえ、辛辣なコメントがついて傷ついた投稿者とかいるんだろうな～とか、いじめに使われたりしないのかな～とか心配したりもしていた。

で、今朝あがってきていたRoastMeを見たら、「私は17歳でうつを患ってます。私を終わらせてください」みたいなコメントとともに気弱そうな男子の顔写真が投稿されていた。

反射的に「この子をRoastするのはマズいのでは」と思いながら人気コメント一覧をみたら、びっくり。

彼を励ます暖かいコメントばかりが、ずらりとならんでいた。

そしてスレの管理人が「君たちのコメントはルールに反してるのでこのスレはRefuseな。でも君たちはfucking nice」とコメントが残されていた。

これが古き良きインターネットのヌクモリティなんだよ。まだまだネットも捨てたもんじゃないと思ったね。

Permalink | 記事への反応(0) | 10:34

These Terms of Service ("Terms") are a legal agreement between we and you ("you"). By installing or using any application ("Service") you agree to be bound by these Terms. By accessing or using the Service, you agree that you have read, understood, and accept to be bound by the Terms. We reserve the right, in its sole discretion, to modify or revise these Terms at any time, and you agree to be bound by such modifications or revisions. If you do not agree to the Terms, do not use the Service.

Users are responsible for periodically viewing the Terms. Your continued use of the Service after a change or update has been made will constitute your acceptance to the revised Terms. If you do not agree to the Terms your only remedy is to discontinue your use of the Service and cancel any accounts you have made using the Service.

We reserve the right to refuse any user access to the Services without notice for any reason, including, but not limited to, a violation of the Terms.

You represent that you are 13 years old or older. If you are between the ages of 13 and 18, you represent that your legal guardian has reviewed and agrees to the Terms.

Intellectual Property/Ownership

All materials that are part of the Service (including, but not limited to, designs, text, graphics, pictures, video, information, applications, software, music, sound and other files, and their selection and arrangement) are protected by law from unauthorized use.

We grant you a personal, non-exclusive, non-transferable, revocable, limited scope license to use the Service solely for the purpose of viewing and using the applicable Services and for no other purpose whatsoever. Your license to use the Services is limited by these Terms.

User Content

You agree that you are willingly publishing the content on the Service using technology and tools provided by us. You understand a nd agree that you may not distribute, sell, transfer or license this content and/or application in any manner, in any country, or on any social network or another medium without the explicit written permission of us. We reserve the right to remove and permanently delete any User Content from the Service with or without notice.

Rules of Conduct/Usage

You agree that all your communications with the Communication Channels are public, and thus you have no expectation of privacy regarding your use of the Communication Channels. We is not responsible for information that you choose to share on the Communication Channels, or for the actions of other users.

Privacy and Protection of Personal Information

By using the Service, you agree to the collection and use of your personal information as outlined in this Privacy Policy. We may amend the Privacy Policy from time to time, and we encourage you to consult the Privacy Policy regularly for changes.

Cookies

A cookie is a small data file that we transfer to your computer’s hard disk, generally to quickly identify a user's computer and to "remember" things about the user's visit, such as your preferences or a user name and password. The Service sends cookies to your computer when you access or view the content of us. The information contained in a cookie may be linked to your personal information for purposes such as improving the quality of our service, tailoring recommend ations to your interests, and making the Service easier to use. You can disable cookies at any time, although you may not be able to access or use features of the Service.

Third-Party Advertising Companies

We may use third-party advertising companies to serve ads on the Service. We do not provide any personal information to third-party advertising companies on a non-aggregate bas is. Our system and the third-party advertising technology may use aggregate information, non-personal information, Our cookies on your hard drive and your use of the Service to target advertisements. In addition, advertisers may use other third-party advertising technology to target advertising on other sites. If advertisements are served to you, a unique third-party cookie or cookies may be placed on your computer. Similarly, third-party advertising companies may provide us with pixel tags (also called “clear gifs” or “beacons”) to help manage and optimize online advertising. Beacons enable us to recognize a browser’s cookie when a browser visits the site on which is a beacon is located, and to learn which banner ads bring users to a given site.

Changing or Deleting Your Information

You may review, update, correct or delete any personal information by changing the applicable information in your profile page on Facebook and/or another social network (s). If you completely delete all this information, your account may become deactiv ated. If you would like us to delete your record in our system, please contact us and we will attempt to accommodate your request if we are not legally obligated to retain the record.

Security

We have put in place reasonable technical and organizational measures designed to secure your personal information from accidental loss and from unauthorized access, use, alteration or disclosure. However, we cannot guarantee that unauthorized third parties will never be able to overcome those measures or use your personal information for improper purposes. Also please note that email and messaging systems are not considered secure, so we discourage you from sending us personal information through these mediums.

Policy Regarding Children

The Service is not geared toward children under the age of 13 and we do not knowingly collect personal information from children under the age of 13. If we learn that a child under 13 has provided us with personal information we will delete such information from our files as quickly as possible.

Disclaimer of Warranty; Limitation of Liability

You agree that your use of the Service shall be at your sole risk. To the fullest extent permitted by law, We, its officers, directors, employees, and agents disclaim all warranties, express or implies, in connection with the website and your use thereof including implied warranties of title, merchantability, fitness for a particular purpose or non-infringement, accuracy, authority, completeness, usefulness, and timeliness. We make no warranties or representations about the accuracy or completeness of the content of the Service and of the content of any sites linked to the Service; We assume no liability or responsibility for any (i) errors, mistakes, or inaccuracies of content, (ii) personal injury or property damage, of any nature whatsoever, resulting from your access to and use of the Service, (iii) any unauthorized access to or use of our secure servers and/or any and a ll personal information and/or financial information stored therein, (iv) any interruption or cessation of transmission to or from the Service, (v) any bugs, viruses, trojan horses, or the like which may be transmitted to or through the Service by any third party, and/or (vi) any errors or omissions in any content or for any loss or damage of any kind incurred as a result of the use of any content posted, emailed, transmitted, or otherwise made available via the Service.

In no event will We, its directors, officers, agents, contractors, partners and employees, be liable to you or any third person for any special, direct, indirect, incidental, special, punitive, or consequential damages whatsoever including any lost profits or lost data arising from your use of the Service or other materials on, accessed through or downloaded from the Service, whether based on warranty, contract, tort, or any other legal theory, and whether or not We have been advised of the possibility of these damages. The foregoing limitation of liability shall apply to the fullest extent permitted by law in the applicable jurisdiction. You specifically acknowledge that We shall not be liable for user submissions or the defamatory, offensive, or illegal conduct of any third party and that the risk of harm or damage from the foregoing rests entirely with you.

You agree to indemnify and hold We, and each of its directors, officers, agents, contractors, partners, and employees, harmless from and against any loss, liability, claim, demand, damages, costs and expenses, including reasonable attorney's fees, arising out of or in connection with (i) your use of and access to the Service; (ii) your violation of any term of these Terms of Service; (iii) your violation of any third party right, including without limitation any copyright, property, or privacy right; (iv) any claim that one of your User Submissions caused damage to a third party; or (v) any Content you post or share on or through the Service.

General

By visiting or using the Service, you agree that the laws of UK, without regard to principles of conflict of laws and regardless of your location, will govern these Terms of Service and a ny dispute of any sort that might arise between you and us.

Contacting Us

If you have any questions about these Terms of Service, please contact us at otoco.contact@gmail.com

Permalink | 記事への反応(0) | 11:52

2019-01-06

■anond:20190106175516

あちこちのWebサービス（当然社外）を１つの Passwordで使いまわしてる件についてはどうお諌めすれば……。

っていうか社内のサービスもそのPassなのは。

Permalink | 記事への反応(2) | 18:07

2018-12-20

■anond:20181220173808

機器のマニュアルにそう書いてあるんや。

初期パスワード：password って。

勝手に変えたら、後からマニュアル読んだ人が困るやろ？

Permalink | 記事への反応(0) | 17:40

■会社のパスワードって、passwordが多くね？

時々p@ssword

Permalink | 記事への反応(1) | 17:38

2018-11-14

■接続環境が変化した、不審なアクセスを検知したためログインを制限

やってみたがテザリングだとめっちゃ頻繁にパスワード変更要求されるな

パスワード変更リンクが届くGMail開きっぱなしだ

PASSWORD→PASSWORD+2→PASSWORD→PASSWORD+2→ で乗り切ってるが

アクセストークンとか保存しろよと思うが、満喫とかで不特定人がログインするような環境も想定してるんだろうな

スマホアプリで表示するワンタイムパスワードとどっちが面倒だろうか…

Permalink | 記事への反応(0) | 07:28

2018-11-09

■接続環境が変化した、不審なアクセスを検知したためログインを制限

A→B→Aとリモホが変化してもやっぱりA→BとB→Aの切り替えの際にパスワード再設定は必要らしい

Aはすこし前にログイン経歴があるからよしとします、とはならないようだ

JRの特急乗りながらテザリングで遊んでみたい

なお、PASSWORD→PASSWORD2→PASSWORDみたいな変更は可能っぽい

直近にユーザーの環境で漏れたかもしれない判定をしたパスワードへ再度戻すことができるってアカウントハックアラートの意味あんのかそれ

Permalink | 記事への反応(1) | 23:32

2018-10-09

■SSH(d)の不思議

PermitRootLogin yes

PermitRootLogin no

はファイルの先頭側に近い方が優先されるし

PasswordAuthentication noにしても(Root ログイン不可能な状況下として)rootで入ろうとすると

Passwordを聞かれる。謎

Permalink | 記事への反応(1) | 23:59

2018-09-22

■JWTに関してのお伺い

http://b.hatena.ne.jp/entry/s/co3k.org/blog/why-do-you-use-jwt-for-session

適当にコメントを書いたら

スーパーエンジニアに「そういうことではない」

と厳しい叱責を受けたため、無能の見識を書いてみた。

「聞くは一時の恥、聞かぬは一生の恥」のとおり、

せっかくの機会のため、びしばしセキュリティに関する認識の甘さを指摘してほしい所存

expの期限と任意でセッションが切れないデメリットに対する私見

作ったシステムではexpは約1時間でやってしまいました(機密保持契約違反を恐れ多少ぼかしております)

私は無能なのでたぶんユーザーから報告を受けて

確認している間に1時間はかかるからいいやと思ってしまっていた

師はきっとJWT生成直後3秒でユーザーが

「これは、セッションハイジャックか・・・！？」

と気づいて通報

そして師が2秒で

「これは、セッションハイジャックだ！」

と検知してセッション遮断、秒速で一億円の被害が出るところを阻止する前提なのではないかと推測している

これは確かにJWTだと厳しそうだ

そもそもログインできるアプリなら

セッションハイジャック成功直後にパスワードを変更された場合

セッションを任意に切れることに意味はないのでは、と思えてきたが、浅はかだろうか

(師はログインを即座に検知してセッションを切れるから問題ないのか)

とにかくアカウントロック機能を作れば上記の懸念全てにきれいに対応できそうに見えている

「定期的な鍵交換が必要」に関する私見

この理屈だと例えば.envに書くような他のkeyも定期的な交換が必要に見える

これはまずい、自分の今までの見識の甘さを思い知らされた

今使っているフレームワークのリファレンスを見たが

keyは初回に設定したのみで、定期的な交換を勧める文が見つからない

私の検索力不足なのかと思ったが、もしかして彼らもこの危険性に気付いていないのではないか

JWTはhash化してつないでいる前提で

hashのkeyを総当たりで破る仮定で書く

私は無能なのでライブラリを用いることにしている

32文字のkeyが生成された

解読時間は下記を参考に、計算はwindows10の電卓アプリを用いて手動で行った

https://ja.wikipedia.org/wiki/%E7%B7%8F%E5%BD%93%E3%81%9F%E3%82%8A%E6%94%BB%E6%92%83

英数字大文字小文字で約60の時は10桁で20 万年と書いているが

現代の解析技術は20万倍は速度が出ると仮定して1年として計算する

果たして、どのくらいの速度で鍵はやぶられると推定されるのか

とりあえず60を10乗した時点で(20 文字相当)

6.0466176e+17

日本語に直すと60京4661兆7600億年かかる計算となった

実際にはこれが6.0466176e+17倍されさらに3600倍されつまりどういうことだ

これだけ長くともkeyの交換は必要なのであろうか

そもそも師は何年で交換したら安全と書いていないが、何年なら安全という意見だったのだろうか

「JWTはセッション IDを含めれば安全」に関する私見

師から「そういうことではない」と指摘された点である

私の理解ではとかくuser_idのみ必要なら意味がないと思っていたため落ち込んでいる

まず、IDとpassを内蔵するネイティブアプリに対するapi サーバでの実装経験しかないこと

JWTが切れたら都度IDとpassを投げる方向でリフレッシュトークンは実装しなかったことを告白しておく

そのためapi サーバで上記前提で用いた場合に考えたことを書く

web アプリのJWT実装経験はないので、そちらの論は差し控えさせていただく

JWT送信→user_id取得

では危険で

JWT送信→セッション(cookie 形式?)送信切り替え→セッションからuser_id取得

だと安全になるのか検討する前提で記載する

とりあえず思いついたのは下記だった

通信途中で傍受されてログイン 情報が奪われる危険が上がる

アプリ から直接ログイン 情報が奪われる危険が上がる

通信途中で傍受される危険に関して

tokenはheaderにbearerで付けユーザー ID(あるいはそれに代わる特定可能な識別子)が含まれる

おそらく一般構成の仮定で書く

httpsで通信するのでパケットキャプチャによる傍受は不可能と思っていた

(httpで通信するのはJWTとかcookieとか関係なく傍受できるため考慮しない)

0に何をかけても0なので、何回送っても解読されないならJWTを何回送っても問題ない

というかJWTが抜けるなら同様にheaderに付けるcookieでも抜けると思うので

JWTだからといって危険性に差はない、という論拠により安全性は変わらないという個人的結論になった

※余談だが、たまに送る回数が少ない方が安全という

言説を見るのだが、個人的には上記の理由で納得できていない

アプリ から 情報が抜かれる危険性に関して

クライアントがネイティブアプリの場合、

攻撃者がアプリに保存されたJWTが取得できるならIDもpassも同じ方法で抜けそうに見えた

(厳密には保存場所が違ったかもしれんが実装依存なので同一とする)

その前提のため、わざわざ

JWT送信→セッション(cookie 形式?)送信→セッションからuser_id取得　

で接続しても、おそらくcookie 形式で送れる何かもJWTらと同じ方法で抜かれると思われる

つまり cookieだろうがJWTだろうがアプリから直接情報が抜かれる危険性には変わりがないという結論になった

結論

つまり cookieだろうがjwtだろうがidとpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

でいいじゃん、わざわざcookieと同様の形式を間に挟むの無駄じゃん、となりコメントの発言に至った

ここまで書いて、常にJWTにsession_idを含めておいて送ることを意図されていた可能性にも気づいたが

それならもっと無駄なため考慮しない

セッションにするメリットとして唯一思いついているのは任意にサーバ側でセッションを切れることだが

それを指していたのであろうか

それは最初の段落の問題と同一と思っている

余談だが、ブコメの雰囲気に日和って「ユーザー IDのみ入れ」(そもそもJWTを自然に作れば入るのだが)

というセッションストア的にJWTに他の情報を入れると入れない時に比べて危険性があがることに同意したような記載をしてしまったが

結局JWTが奪えたら中身に関係なくbearerとしてセットして接続するだけなので

正直JWTを使った時点でついでにセッションストアのように使おうが使わまいがセキュリティ的にそこまで変わらないのでは、と思っている

強いて上げるならセッションに保存している内容が分かる可能性があり、サーバー内部の実装が推測できる危険があるくらいだろうか

でも暗号化したらよいのでは、と思った

私的 結論

expの期限と任意でセッションが切れないデメリットに関して

expを適切に設定しつつ、必要ならアカウントロック機能を入れる

(アカウントロック機能はJWTに関係なく被害の増加を抑えられる可能性がある)

定期的な鍵の交換について

長いkeyを設定すれば不要

「JWTはセッション IDを含めれば安全」について

少なくともapi サーバ→ネイティブアプリに関して、セッション IDを含めても危険性は変わらない

正直web アプリでも大して変わらんのでは、と思っているのは内緒である

と思ったので短慮なところ、見落としている視点があるようなら今後のためにご教示をいただきたく

以上、よろしくお願いいたします

Permalink | 記事への反応(0) | 11:52

2018-03-16

■ネット バンクで悶絶した

普段 ATMで現金の出し入れに使っている銀行口座からネットで振り込もうとしたら、ワンタイムパスワードが使えなくて悶絶した

経緯

振込のページからワンタイムパスワードの入力を求められたので、アプリを起動して6桁の数字を入力（1度目）
パスワードが違いますエラーが出たので、数字を押し間違えたかと思い、別の番号に変更された6桁の数字を入力（2度目）
パスワードが違いますエラーが再び出て、しばらくしてから再びお試しくださいのメッセージとともに振込のページから先に進めなくなる

原因

ソフトウェアトークンはスマホ本体のハードウェア IDとかでも見て生成しているのかもしれない
そのため、旧機種から復元しただけでは異なるパスワードが生成されてしまってるのかも
機種変した場合はソフトウェアトークンのアプリの利用登録を、銀行のウェブサイトでもう一度しないといけないらしい

思ったこと

"ワンタイム"パスワードなのに、input type="password" にしておく理由って何なの？ワンタイムパスワードを不可視にしなければいけない理由を考えて設定したの？ワンタイムパスが更新される10秒の間に、既に俺のログイン IDとパスワードを不正入手して、振込ページを開いたスマホを手にして俺の背後に待機していた悪人が、背中越しにパスワード盗み読んで、不正な振込をされてしまうことを防ぐ対策までしてくれてるの？そんな透明人間だとか時間加速能力者の対策なんていらねえよ。そこまでされたって、そもそも、inputフォームの小さい文字が見えるなら、スマホのトークンアプリに表示されてる数字なんか、もっとでかくて丸見えになってるじゃねえか。ばっかじゃねえの？
「入力されたパスワードが違います」ってエラーが表示されて、「あれ？もしかしたらソフトウェアトークンのアプリがハードウェア IDで管理されているから、スマホの機種変したら利用登録をもう一度しないといけないのかな？やっぱりただ復元しただけじゃダメなんだねてへぺろ」なんて即座に考えるやついるか？普通は「パスワードは黒丸になってるから、入力間違いでもしたかな？」としか思わないだろ。
機種変の都度、再登録が必要なら、アプリのほうに表示出せよ。
ご丁寧に、パスワードが違う入力がされましたってメールが来たけど、そこからロックを解除する手続きくらいさせろよ。「しばらく」ってどんだけ待たせるんだよ。時間くらい書けよ。
ログイン IDとパスワードが割られてるなら、メールアドレスが乗っ取れて、ソフトウェアトークンの再登録もできるし、最後の振込のところだけガッチガチにしたところで、何の意味もないじゃねえか。セキュリティの厳しさとゆるさのバランスおかしすぎるだろ。

Permalink | 記事への反応(1) | 13:30

2018-01-15

■俺のパスワード: password

だけどアカウントが激ムズだお

Permalink | 記事への反応(1) | 22:12

2017-04-19

■今流行ってるOrarioと大学側について思うこと

Orarioについて思うこと

Orarioについて

現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、

ひとまずこの記事については、下記URLにある、京都大学の専門家であらせられる記事について、一人歩きしてる感があるので、

もう少し彼のような上流側（という表現で良いかどうかは不明だが）の専門家ではなく、

下流でプログラムをガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。

https://srad.jp/~yasuoka/journal/611343/

不正アクセスという言葉の曖昧性

Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性と安全性について』(2017年 4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。

Orarioの特性と安全性について、本当にスクレイピング技術をクライアント端末側で行っているのであれば、

この部分は間違いではないと私(匿名で失礼)は考えている。

この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。

KULASISにずっと不正アクセスを繰り返していて

上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である。

逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である。

何せ、開発者が勝手にアカウントを使って入り込んで様々な検証を行う必要があるため、

学生から IDとパスワードを借りたはずだ。

借りてログインするのが不正かというと微妙なラインだと思う。

この辺りにもやっぱり大学教授のいやらしさがあって

KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、

あくまで大学側が定める規約規則から若干外れた使われ方がされているという意味の不正アクセスである。

法律的には、正直不正かどうか微妙なラインになる。

（そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない

開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大の規約によれば、不正アクセスにあたるのかもしれない。

個人的には当たらないと感じるが。

現在動いているアプリは不正アクセスと断言できない

現在動いているものは不正アクセスではなく、

京大の規定に定められたユーザが「特定のブラウジングツール（Orario）」により、

KULASISにアクセスしているのだからアクセスとしては不正ではない。

本当にスマートなWeb スクレイピングで行われているのであれば、Web ブラウザと全く同じ動きをするはずで、

それを不正アクセスと断罪してOrarioは不正というのは表現が汚いと考える。

これはコメント欄にもあるが、

https://srad.jp/comment/3196554

また、ChromeやSafari（及びその他マイナーなWeb ブラウザ）なども御校のWebサーバーよりコンテンツデータを取得し、HTMLを構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか？

ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。

それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、

Web ブラウザの一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう

京大のユーザが開発に携わったかを証明できない以上、彼にとっては不正なのかもしれないが、

ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。

アクセス パターンを公開できない理由とは？

他にもこの部分

Orarioアプリでは「Web オートメーション(Web スクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン（にインストールされているOrarioアプリ）に学生アカウント（大学 ID・パスワード）を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要な情報のみを取得し、Orarioアプリの時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています。
全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ。

この部分も怪しいものである。

Web スクレイピング技術に関して、なぜアクセスパターンが問題になるかが一つ疑問である。

下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング（切り貼り）している。

それをアクセスパターンを解析で一体何が取れるのか？という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。

もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティの観点上公開すべきではないだろうか、

逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである。

ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから、

アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、

学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である。

学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。

そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、

現在すでにスクレイピングが確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。

（ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……

（もちろん、アクセスログを見て、ログインページから Web スクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。

たとえKULASISが京都大学がオリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。

同様に日立や富士通も同じような大学教務事務パッケージがあるが、

基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、

本当だろうか？嘘を書くのもいい加減にしろ？　と思う。

大学側について思うこと

なぜOrarioが学生に人気か

UIが糞（システムのスマートフォン対応がノロい）だからアプリが流行るということに気づくべき。

富士通、日立にしてもそうだが、APIを提供したほうがいいのではなかろうか。

とくにKULASISだったか何だったは、京都大学謹製と聞いている（違ったら失礼

少なくとも他の大学教務事務パッケージではなかったと記憶している。

であれば、京都大学がAPIを提供し大学側で専門家を集めてOrarioを超えるものを作ってはどうか？

大学の予算確保の問題

実際大学でこういうことをやろうにも、問題になってくるのは予算で。

大学は、縦割り構造で、横とのつながりが極端に薄く。

教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。

これが実に糞で。

一つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。

その辺りが難しいのは知っているので文句は言えないものの、

ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。

まとめ

学生がアホ　→　仕方が無い若いんだし

大学がアホ　→　学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ

教授がアホ　→　曖昧な表現で、素人を先導しようとするのが見え見えで気に入らない

Orarioアホ　→　コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ

以上です

Permalink | 記事への反応(4) | 21:37

2016-08-04

■LastPassのセキュリティチェックをやってみた

サイトごとのパスワードの強度で、某サイトでスコア0って表示されてて、いったい何設定してたっけと確認したら「password」だった

たしかに0点だ

これまで被害がなかった幸運に感謝したい

パスワードはもちろんすぐに変えた

Permalink | 記事への反応(0) | 00:42

2016-07-16

■【質問】msnのlive .jp メールをthunderbirdが受信できなくなった件について

なんか先月ぐらいからまったく受信できていない

原因は正しいパスワードを入力しているにもかかわらず下記のポップアップメッセージがでるから。

「[メールアドレス名]　アカウントのエラー

　ユーザ[メールアドレス名]のパスワードを送信できませんでした。メールサーバ pop3.live.comからの応答：

Autehntication failure: unknown user name or bad password. [Error="ProxyNotAuthenticated"

AuthResult=0 Proxy=[なんか意味ありげな文字列なので伏せる].com:1995:SSL]

」

パスワードが間違っていない。

ブラウザからログインをすることはできた。

live .jpのアカウントは2つあるがどちらともにログインができなくなった。

原因を教えてほしい。

Permalink | 記事への反応(0) | 18:37

2016-01-22

■http://anond.hatelabo.jp/20160121215625

パスワード入力強制は反対。だって、毎回入力するの面倒じゃん

グーグルプレイは一度設定したら有料アプリを買う時も黙って買えるから複雑な使い回しじゃ無いパスワードを設定できるけど

iOSは毎回パスワード聞いてくるのが面倒なんだよね。PC サイトならカンペからコピペできるけどiOSじゃ無理だし

アップル的には指紋使えって事なんだろうけど、指紋なんて普段からあちこちにベタベタつけてるもんを認証に使いたくない

もちろんスマホで大文字小文字記号の入ったパスワードを入力するのなんてダルいし。せめてIEとかにある、一時的にパスワードのマスクを解除する機能を標準UIとして提供してくれればな

結果的に簡単なpasswordになってしまう

IOSで自分の運用は大丈夫！って胸を張って言える人はどんな事してるんだ

指紋は論外だし、英数記号の使い回ししてないユニークなパスワードを完全に覚えて、アプリ買うたびに入力してるの？

Permalink | 記事への反応(1) | 14:10

■http://anond.hatelabo.jp/20160121195448

iOSの仕様だね。端末識別子を何とかゲットして広告用追跡に使おうとした悪い大人が過去にたくさん居た弊害。

暗号化バックアップですべてそのまま複製できるのもiOSの仕様。じゃないと不便だしな。

LINEに限らずいろんなアプリで同じ危険性がある。

ま、防御する対策は簡単。

1. 新しい端末を購入(または交換)したら、まずは「iPhoneのバックアップを暗号化する」を有効にしてbackupする。普段はiCloud Backupのやつもいいからまずは1回やれ。パスワードは当然突破されないようなものにすること。

2. iCloud backup派ならiTunesかiPhone側でiCloud backupに戻してiCloud backup実行。

3. PC上の暗号化されたbackupが不要なら、設定→デバイスから該当するバックアップを削除。

これだけ。iCloud backup設定にしたうえでPC上のbackupを削除したとしても、1で入力したbackup passwordを知らない限りは「暗号化バックアップ」自体が出来なくなる。どうしても暗号化バックアップをしたければ端末を完全初期化するしかない。

旧端末は初期化してさっさとじゃんぱらにでも持っていけ。どうしてもそのまま保管したいなら、旧端末でもbackup passwordを設定した上で、ちゃんとしたlock passwordを設定して電源を落としておく事。

上記手順の1をやろうとしたタイミングで設定した覚えもないのにパスワードを聞かれ、心当たりがあるpasswordを入れても拒否られた場合。

過去に自分でやっててpasswordを忘れたとかでなければ、すでにやれられてる可能性がある。

心配ならLINEにID/PWを登録したうえで一回削除して、ログインしなおすこと。ログは消えるがコピー端末側も締め出される。

暗号化passwordがわからないケースでは、犯人だけが passwordを知っている可能性がある。そうなると、せっかく締め出してももう一回やられるかもしれない。

その場合は、もはや完全に安全にするには端末を初期化してまっさらな気持ちで1からやり直しするしかない。初期化前にソシャゲのアカウント登録忘れないようにな。泣くぞ。

暗号化パスワードを他と共通にしてしまうような奴や、設定しても忘れてしまうような奴や、PC持ってないやつは、まぁなんだ、あきらめろ。不倫はよくないぞ。

Permalink | 記事への反応(0) | 01:15

542 仕様書無しさん sage 2015/01/23(金) 12:39:08.24 
>>541 
ちょっと違うと思う。IT疎い人はこういう説明でなるほど開発会社が悪い！となって、裁判官も多分そう思って判決出してる。 
普通に運用しててビニール入るのは欠陥だが、SQLインジェクションは欠陥ではない。 

俺が思うに、ローカルのディレクトリが外から見えるようになってたとか、認証掛けてるつもりがかかってなかったとかが重過失。 
何故ならそれは家に鍵を掛けずドアが開いているか、ドアがないのと同じだから。 
泥棒するつもりのない人でもうっかり入って来れちゃう。 

それに対しSQLインジェクションは犯罪者がすること。悪意を持って行われる攻撃行為で、一般人はやらない。 
家で言うと鍵のピッキングだな。 
ピッキングで泥棒入ったら工務店が悪い、みたいなのが今回の判決。 

ピッキングにどこまで耐えられるように作るべきか、事前に仕様で決めておく必要がある。今回はSQLインジェクション対策が仕様に入っていなかった。 
仕様にないから強い鍵を付けなかったら破られた。これを重過失ってのはひどすぎ。重過失って故意に匹敵するレベルの過失だぜ。契約書の賠償上限無効にしてしまう程の。 

俺の考えはこうだ。SQLインジェクションなどセキュリティ対策の実装について、 
仕様に書いてあった → 重過失 
仕様に一切無し →無罪または普通の過失 

パスワードがadmin/passwordとか改善の提案を拒否したとか別の話も話をややこしくしているが、話のコアの部分は以上のようなことだと思う。

Permalink | 記事への反応(0) | 12:53

2015-01-04

■http://anond.hatelabo.jp/20150104125720

HTMLの中でmaxlengthを指定してないサイトってそんなに多いの？

しかも、そんな多くのサービスに登録しようとしてんの？

何やってんのよ？

（追記）あーわかった。ちょっと考えたが、maxlengthの指定はtype=passwordに対しては害悪かもしれんね。だからmaxlength指定の無いサイトの方が多いのかな？そういえば調べた事無かったわ。

（追記の追記）ちらっと見たところ、はてなもbitbucketもmaxlength無いんだなあ。

maxlength指定してるとブラウザが勝手に文字を切り落とすし、クライアントサイドのバリデーションも無いし、ことpasswordについてはmaxlengthは要らない子なのか。

それにしたって、パスワードに文字数制限があるのはやっぱりダメだよなあ。どうせハッシュした結果だけをDBなりに保存するんだろうから、長さなんて無制限でいいはずだわ。まあサーバがPOSTを受け付ける最大長が上限になるだろうけど。

Permalink | 記事への反応(0) | 20:13

2014-09-05

■

http://anond.hatelabo.jp/20140905152346

http://anond.hatelabo.jp/20140905152302

あ、いや、全然上級なことはなくて。

単に「社内にある昔ながらのモノ」を使わないといけないというだけで・・・

今どき代表 FTP、しかもftpsでとか。一社に一台Windows Active Directoryとか。

特に AD、つなぐのにldap://ではNG、ldaps://じゃないとダメ（書いてねーぞ！）とか、

　my $charmap = Unicode::Map8->new('latin1') or die;

　my $uniPass = $charmap->tou('"' . $password . '"')->utf16le();

とかPerlに慣れてもイミフな事しないとダメとかね・・・。

で、Active Directoryのついでに、データベースとグループウェアとレン鯖のメールアカウントも同時に登録しないといけない。

零細企業でよくありそうなカオスな管理者業務ですね。

共感とかいらないです。もう、ただの愚痴だったと思って下さい。Ruby から始めていたら挫折したに違いない・・・ただそれだけです。

すみません。

Permalink | 記事への反応(1) | 15:59

2014-06-13

■UFJ推奨のセキュリティーソフトが信頼できないんだけどこれどうすれば

MUFJのオンラインバンキングを申し込んでみたのだがそこでセキュリティーソフトを推奨された。

　こいつだ。http://www.trusteer.com/ja/products/trusteer-rapport-for-online-banking-ja

残難ながらこれのダウンロードリンクはhttpsでは提供されていない。賢明な諸兄はご存知の通りhttpsで提供されていないソフトは信頼しないことが大原則だ。

ファイルがhttpsで提供されない場合はhttpsで提供されているMD5 情報などを元にファイルの正当性を確認する必要がある。

何と言っても、オンラインバンキング専用セキュリティーソフトだ。最大限の注意を払う必要がある。

問題がある場合は私の全財産がどこかに送られてしまう。

さて、困惑した私は会社のサポートチャットに問い合わせをすることにした。

"httpsで提供されていないソフトウェアをどうやって信頼すればいいのでしょうか？"というのが、はじめの質問である。

以下がそのログの抜粋（担当者のフルネームが表示されていた箇所を「サポート」と伏せている）

サポート: httpsで提供されていないソフトは、インストールの際にソフトウェアのデジタル署名をご確認ください。
増田: 私はOSXを使っていますが、
増田: Trusteerエンドポイント保護のアンインストール.appを実行する場合はインターネットからダウンロードしたソフトですが信頼しますか？というようなことが表示されますよ。
サポート: はい。アップルストアからの提供品ではないためそのようなメッセージが表示されることもございます。
増田: また、OS Xでは署名はappleが認証したデベロッパーが開発したソフトウェアであることをを証明してもデフォルトでは提供元を表示する機能は無かった様に記憶してますが
増田: 実は提供元を保証する様に機能があるのでしょうか？
サポート: ルート証明が正しければ正しい提供元としてTrusteerが表示されますので、ご確認いただけますでしょうか。
増田: えーと、それはどのようにすればいいのでしょうか？
サポート: 申し訳ございませんが、この内容はRapportのサポート範囲外となりますので、お答えできかねます。インターネット等でお調べいただけますでしょうか。
サポート: 正規のソフトウェアである事をご確認いただくための情報としては、組織に「Trusteer LTD」が表示されていることとなります。
増田: ではもう一点
増田: httpsで接続先が偽物というのはどのような場合でしょうか？　考えられるのは 1.接続先の秘密鍵が漏れている場合 2.接続もと(ブラウザなど)が信頼できない認証局を信頼している 3.サイトがハックされているなどのケースが考えられますがどのようなケースを想定していますか？
サポート: サイト自体がハッキングもしくは、ファーミングされたケースを想定しております。
サポート: ファーミングされた場合、偽者のSSL証明書を利用することでhttps 接続となりますが、接続先は偽者、となります。
増田: 私がrapport.pkgをinstallしようとする際にはpasswordを求められるまでの間にアプリケーション提供元や署名の表示などは行われませんでしたが、これは問題ないとお考えですか？
増田: おそらくwindowsだと提供もと証明などがでてくるのでしょうけど。
サポート: 署名の表示は、お客様の操作によって表示されるものですので、Macの仕様となります。
増田: なるほど、比較的容易な攻撃方法である DNSポイゾニングなどで間違った接続先に接続した場合、OSX ユーザーは能動的に確認する以外に自衛手段はないということでよろしいでしょうか？
サポート: はい。Rapportを導入していない状況ですので、お客様ご自身の自衛手段となります。
増田: 今後httpsでの提供する計画はありますか？
サポート: 予定につきましてはお応え出来かねますが、ご要望として担当部署に伝えることは可能でございます。
増田: OSX ユーザーがRapportインストーする際にそのような自衛手段を案内することはRapportのサポート範囲外ですか？
サポート: 申し訳ございませんが、そうなります。ただデジタル署名の情報でしたら先ほどご案内した通りでございますので、デジタル署名をご確認ください。
サポート: また、デジタル署名をご確認いただくことで、ソフトウェア自体に改竄が加えられていないこともご確認いただけますので、http/httpsに関わらず確かな方法となります。
増田: その確認方法は自分で調べないといけないということですか？
サポート: 申し訳ございませんが、ご自身でお調べしていただくようお願い申し上げます。
増田: わかりました、ありがとうございます。　予算さえあれば私でも御社のセキュリティーソフトの偽物を容易に配布できることをよく理解しました。
サポート: こちらこそお問合せありがとうございました。
サポート: お客様への回答は以上となりますが、他に何かご不明な点などはございますでしょうか。
増田: いえ、ありがとうございます。
サポート: Trusteer・カスタマーサポートのチャットでサポートをご利用いただきありがとうございます。

ちなみに私は.pkgや.appの署名を確認する方法を見つけることは出来なかった。

Permalink | 記事への反応(0) | 20:01

2014-06-11

■SQL Server sa ユーザーがロックされてしまった場合

シングルユーザーで起動（MSDN LIBRARY に詳細有）

Windows 認証で管理者ログインができるのであれば osql から -E でログイン後、ALTER LOGIN sa WITH PASSWORD='パスワード' UNLOCK; GO

Permalink | 記事への反応(0) | 21:28

2013-11-27

■Mathematicaのライセンス キーを受け付けてもらえない

I'm installing "Mathematica for Students" on my own home computer, but my license number doesn't be accepted.

The web site (https://register.wolfram.com/index.en.cgi) shows;
Wolfram Research Product Registration

Our system is unable to issue a password or process the registration for this license number.
Please contact Wolfram Research Customer Service, including your license number, name, address, and telephone number in your correspondence.
We apologize for this inconvenience.

I had tried instlling this software on a lab's computer 8 days ago.
But I have understood that I cannot install Mathematica on a lab computer, by your e-mail.
So I uninstalled Mathematica on lab's computer.

Permalink | 記事への反応(0) | 23:15

2013-08-26

■初めてのRailsでサイト作った人が使ったGem リスト一覧

ども。

以前、はてな匿名ダイアリーで日記を書いた者です。

→【Ruby on Rails勉強】 xvideosまとめサイトっておいしいの？

上の記事でも書いていますが、Railsはおろか、Rubyを初めて触った人間がゼロから Webサービスをリリースするために利用しているGemを公開したいと思います。

作ったサービス

サイト名	onalife(オナライフ)
URL	http://www.onalife.com
説明	xvideos動画の共有・ユーザー参加型のまとめサイト

使っているGem

sqlite3

developmentモードで起動する際のデータベースはsqlite3を使うようにしています。

コーディング→サーバー起動→動作確認→コーディング…という流れになりますが、サーバーを起動する際に、

$ rails s

と実行するだけでサーバーが起動できるため大変手軽です。

サーバー起動後はブラウザで http://localhost:3000/ でアクセスすれば開発用のサイトを確認できます。

mysql2

production モード（本番環境）で利用するのはMySQLを使うようにしています。

理由は他のWebサイトで推奨されていたため。

sqliteの場合だと、単純にDBのデータをファイルとして扱っており、同時に複数アクセスがあった際、最初のアクセス中にファイルがロックされてしまう仕様との記事をどこかで見たため、MySQLを使うようにしています。

developmentとproductionで動作を分けるには、 config/database.ymlで分けることができます。

development:
adapter: sqlite3
database: db/development.sqlite3
pool: 5
timeout: 5000
production:
adapter: mysql2
database: production.mysql
encoding: utf8
pool: 5
username: <yourname>
password: <password>
timeout: 5000