「Password」を含む日記 RSS

はてなキーワード: Passwordとは

2019-07-09

パスワードは当たり前のようにPCに付箋で貼ってあるし

サーバログイン用の共通パスワードpasswordに毛が生えたようなもの

ルーターとかのデフォルトパスワードが設定されているもの

共通パスワードに変更せずにデフォルトパスワードエクセル管理してるし

そのエクセルファイルはv1からv20ぐらいまでoldフォルダに入っていて最新版にはv21_最新.xlsxかになってるし

予算管理システムIEしか動かないし

しかシステムデータを1年分しか検索できないか

予算管理システムに投入した画面のスクリーンショットを所定の共有フォルダPDFで保存する決まりになっているし

それがちゃんと格納されているかどうかを四半期毎にチェックする必要があって

予算管理システムから吐き出したcsvファイルエクセルマクロで読み込んで

出力されたエクセルのシートを印刷して

ファイルを全部チェックできたら課長サインを貰って

それをPDFで保存して所定の共有フォルダPDFで保存する決まりになっていて

流石にこの現状をどうにかしようと予算管理システム刷新したんだけど

刷新を指揮していた人が異動して引き継いだ人は意味を分かっていなかったらしく

予算管理システムデータちゃん検索できるようになったのに

システムのどの画面のスクリーンショットを残すべきか議論して

結局OKボタンを押す前の状態スクショすることに落ち着いて

やっぱり四半期毎のチェックは必要だったりして

この状態デジタルトランスフォーメーションとか言い出してる地獄

2019-02-01

欧米インターネットヌクモリティを感じた話

海外版増田ことRedditで、久々に古き良きインターネットヌクモリティ(死語)に触れたので共有

今朝Redditを眺めていたら、「r/RoastMe」のとあるスレがPopular(ホッテントリみたいなもの)に上がってきていた。

「r/RoastMe」というのはReddit内の大人気subredditのひとつで、自分顔写真晒し不特定多数から感想コメントをもらうという過激な遊び場。

例えば、ダレノガレ明美みたいな派手目の女子が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」とコメントが残されていた。

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

2019-01-29

Privacy Policy

Accepting the Terms & Privacy Policy

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 and 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 recommendations 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 basis. 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 deactivated. 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 all 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 any 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

2019-01-06

anond:20190106175516

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

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

2018-12-20

anond:20181220173808

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

初期パスワードpassword って。

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

2018-11-14

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

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

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

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

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

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

2018-11-09

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

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

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

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

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

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

2018-10-09

SSH(d)の不思議

PermitRootLogin yes

PermitRootLogin no

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

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

Passwordを聞かれる。謎

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だろうがidpasswordの組だろうが同じ危険性で抜かれる可能性があり、いずれでも同じことができるなら

JWT→user_id

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

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

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

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

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

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

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

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

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

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

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

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

私的結論

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

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

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

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

長いkeyを設定すれば不要

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

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

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

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

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

2018-03-16

ネットバンクで悶絶した

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

経緯

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

原因

思ったこ

2017-05-02

マストドンAPI

マストドンリポジトリ

ttps://github.com/tootsuite/mastodon

マストドンAPIリファレンスAPI実装済みのライブラリ(サードティ)の紹介

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md

マストドンAPIに関するドキュメントが置いてあるディレクトリ(色々ある)

ttps://github.com/tootsuite/documentation/tree/master/Using-the-API

マストドンアプリ認証にdoorkeeperを使ってるので認証APIはこっちを参照する必要がある

ttps://github.com/doorkeeper-gem/doorkeeper/wiki

マストドンドキュメントで紹介されてるAPI実装済みのライブラリ(サードティ)を使うのが一番ってっとり早い

以上

=====

わざわざ自前でAPIを叩くコードを書く

step1

アプリマストドンサーバー登録する

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#apps

POST /api/v1/apps

必要データをPOSTするだけ、難しくない

アプリ登録をわざわざコーディングする場合ライブラリとして作って提供する場合くらい(?)

(アプリ複数インスタンス対応させる場合はやはりコード書くしかないけど)

(登録したIDを自前サーバーで持って同一アプリで共有するとか?)

別にhtmlフォーム作って送信するだけでも登録できる

(ローカルhtmlファイル作ってブラウザ表示して必要入力してsubmit送信するだけ簡単)

<form name="regsterapp" method="POST" action="http://SERVERNAME/api/v1/apps">

<input name="client_name" type="text" value="">

<input name="redirect_uris" type="text" value="urn:ietf:wg:oauth:2.0:oob">

<input name="scopes" type="text" value="read write follow">

<input name="website" type="text" value="">

<input type="submit"></form>

step2

ユーザに対してのアプリ認証

doorkeeperについて知る必要がある

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

このページに書いてあるgrant_type=password認証法ではread権限しか貰えないぽい

grant_type=authorization_codeで認証する必要がある、これ読めば早い

ttps://github.com/doorkeeper-gem/doorkeeper/wiki/Authorization-Code-Flow

GET /oauth/authorize

必要パラメータ(※1)つけたリンクアプリ認証したいユーザに踏んでもらい許可を押してもらった上でそこで表示されるコード(RETURNED_CODE)を使う必要がある

(自前サーバーなどでリダイレクトで受け取ることもできるけど)

その表示されたコード(RETURNED_CODE)を使って次のAPIを叩くと認証完了する(アクセストークンをゲットできる)

POST /oauth/token

これもただのPOSTになるのでそんなに難しくない

さっきのアプリ登録みたいにhtmlとかで簡易にもできるけどアプリ秘密キーを使うので公開はダメでしょうな

※1

ttp://SEVERNAME/oauth/authorize?client_id=YOUR_CLIENT_ID&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=read+write+follow

scopeというパラメータで取得したい権限指定する必要がある

step3

認証終わってアクセストークンをゲットしたらもうAPI使えるので

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/Testing-with-cURL.md

これの2番目に書いてあるようにHTTPのヘッダに Authorization: Bearer ACCESS_TOKEN を加えてから

APIの叩けばよい

toot(トゥート)はAPIドキュメントではstatusという表現になってる

ttps://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md#statuses

POST /api/v1/statuses

がtootするためのAPI

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

また、ChromeSafari(及びその他マイナー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アホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ


以上です

2016-11-20

WiMax IP電話 grandstream

VoIPアダプタ「Grandstream Handy Tone-701」のIPアドレス確認

管理画面にアクセスIPアドレス確認

受話器、「***」で発信し、「02」をプッシュ。

DHCPで割り当てられたIPアドレスが読み上げられる。

VoIPアダプタ「Grandstream Handy Tone-701」のファームウェアアップデート

アップデートなしでは、うまく動作しませんでした。

事前にファームウェア(1.0.7.3:2015/02/14時点の最新版)をGrandstream Networks社のホームページから

ダウンロード

確認したIPアドレス管理画面にブラウザアクセスし、管理者用の初期パスワードadmin)でログインし、

ファームウェアアップデート

管理画面に管理者用の初期パスワードadmin)でログインし、以下の設定の確認と変更を行います

<「BASIC SETTINGS」の設定>

# Time Zone

GMT+9:00 (Japan,Korea, Yakutsk)

# IP Address

statically configure as : IP Address / Subnet Mask / DNS Server

DHCPIPアドレスが変わるのが気になったので固定のIPアドレスを設定します。

DNS Serverは、WiMAXルータIPアドレスを設定します。

<「ADVANCED SETTINGS」の設定>

# NTP Server

ntp.jst.mfeed.ad.jp

<「FXS PORT」の設定>

# Account Active

Yes

# Primary SIP Server

smart.0038.net

# NAT Traversal

Keep-Alive

# SIP User ID

通知のあったユーザIDを設定します。

# Authenticate Password

パスワードを設定します。

# Preferred DTMF method

RFC2833

SIP INFO

In-audio

デフォルトから変更しないで使用しました。

# Preferred Vocoder

choice 1 : PCMU

choice 2 : PCMA

choice 3-6 : PCMU

※iLBCが入っていると、音声がおかしくなる・・・

# SLIC Setting

JAPAN CO

VoIPアダプタ「Grandstream Handy Tone-701」の設定確認

・4個のLEDランプがすべて点灯していること。

管理画面(STATUS画面)でHook : On Hook / Registration : Registered / DND : No

VoIPアダプタ「Grandstream Handy Tone-701」の設定作業時の注意点

設定変更は、「Update」ボタンを押したのち「Apply」ボタンを押しますが、着信ができなくなったりしたことがあったため、テスト前には「Rebootボタンを押して再起動することをお勧めします。

2016-08-04

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

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

しかに0点だ

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

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

2016-07-16

質問msnlive.jpメールthunderbirdが受信できなくなった件について

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

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

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

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

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

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

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

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

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

原因を教えてほしい。

2016-06-08

初心者には、JSP難易度が高すぎた。

環境Java8,Eclipse,Tomcat8

プログラミング歴3ヶ月

1.webコンテナの設定が面倒くさい。

Tomcat8では、managerページ開くのに

roles="manager-gui"の追加をしないといけない。

><user username="tomcat" password="" roles="manager-gui"/>

2.JavaプロジェクトだけじゃWarデプロイメントできない。

Jsp入門のページからプロジェクトを丸ごと持ってきた。しかしそれだけじゃデプロイメント出来ないらしい。

Eclipseプロジェクトプロパティプロジェクトのファセット→動的Webモジュールにチェックを入れないといけない。

3.doGetメソッドがないと怒られる

デプロイメントに成功したのでプロジェクトURIアクセスしてみた。

[HTTPGETメソッドは、このURLではサポートされていません。]

doGetというメソッドが無いとダメらしい。仕方ないのでそれっぽいのをコピって貼り付けてきた。

しかし先程のエラーは無くなったが、今度はJspファイルが無いらしい。

4.Jspファイルがない

WEB-INF/直下に置いたのにindex.jspに遷移しない。

>/WEB-INF/classes/index.jsp

仕方がないからフルパス指定すると動いた。

とりあえずわかったこと。Jspは難しく奥が深い。

次はpostとかgetとかその辺を勉強したい。

2016-01-22

http://anond.hatelabo.jp/20160121215625

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

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

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

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

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

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

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

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

http://anond.hatelabo.jp/20160121195448

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

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

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


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

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

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

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

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

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


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

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

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

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

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


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

2015-01-23

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

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

それに対しSQLインジェクション犯罪者がすること。悪意を持って行われる攻撃行為で、一般人はやらない。 
家で言うと鍵のピッキングだな。 
ピッキング泥棒入ったら工務店が悪い、みたいなのが今回の判決ピッキングにどこまで耐えられるように作るべきか、事前に仕様で決めておく必要がある。今回はSQLインジェクション対策仕様に入っていなかった。 
仕様にないから強い鍵を付けなかったら破られた。これを重過失ってのはひどすぎ。重過失って故意匹敵するレベルの過失だぜ。契約書の賠償上限無効にしてしまう程の。 

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

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

2015-01-04

http://anond.hatelabo.jp/20150104125720

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

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

何やってんのよ?

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

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

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

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

2014-09-05

http://anond.hatelabo.jp/20140905152346

http://anond.hatelabo.jp/20140905152302

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

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

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

特にAD、つなぐのにldap://ではNGldaps://じゃないとダメ(書いてねーぞ!)とか、

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

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

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

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

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

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

すみません

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん