Tracking software: find stolen laptops, phones & tablets | PreyGet peace of mind about your devices’ whereaboutsKnowing where your assets are at any given time remains crucial. Avoid losing information about your remote workforce. Use our persistent device tracking & security solution. Get STARTED
セッションやCookie、認証の関係の基礎の基礎 - [Mi]みたいなもの
セッションや認証って難しいですね。 他のテーマ？に比べて、参考資料がウェブ上に少ない。 こればかりは本を買わないといけないかと頭を悩ましています。 はじめに 出来れば個人情報は一切預かりたくないと思っています。 なぜならそれにみあうスキルがないから。 リスクが高いのに、預かる意味がないし。 ただ会員管理というか、利用者の一意性を確保する必要がある場合、メールアドレスだけは預からざるをえません。 そうするとセッションや認証も気合いをいれて使わないと、あっという間にメールアドレス流出に至って大惨事になるわけです。ぐむむ。 できれば、既存の物を利用したいのですが、ログインはソースを見られてしまうとセキュリティ的にも問題があるのでなかなか配布していないようです。 PEAR::Authになっちゃうと、中で何やってるかわからずに使ってしまいそうで、より危険だし。 いつものごとく自分で書いてみて、動作さ
![セッションやCookie、認証の関係の基礎の基礎 - [Mi]みたいなもの](https://cdn-ak-scissors.b.st-hatena.com/image/square/d3ef5004770b447be461a3a29c96d73567baaa4a/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127156572702%2F17680117127156587068%2F1558483403)
高木浩光＠自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合
■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日本のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 （略）こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 （略）iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 （略）契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ
自宅サーバであそぼ: 基本的なセキュリティの設定
/etc/inetd.confの書き換え(不要サービスのコメントアウト) pop-3以外(telnet,swat)をコメントアウトし、アクセス権を600に変更。ついでに変更不可 (immutable)属性をつける。 # chmod 600 /etc/inetd.conf # chattr +i /etc/inetd.conf 起動デーモンの選択 # ntsysv 起動デーモンを選択、設定後は再起動 [*] anacron → × [*] apmd [*] atd → × [*] autofs → × [*] canna [*] crond [ ] dhcpd [*] gpm → × [*] httpd [*] identd [*] inet [ ] ipchains [*] iptables [*] keytable → × [*] kudzu [*] lpd → × [ ] mcserv
SSL／TLS（Part.2）
MACの機能とハッシュ関数 TLSCiphertext構造体で新しく登場するMAC(Message Authentication Code)には、データの改ざん検出、通信相手の認証、この2つの機能が盛り込まれている。本体データにこの情報を付加することにより、通信中の危険性をより多く排除することができ、通信はより一層安全なものとなるのである。 まずMACの使われ方の概念を説明しておこう（図17）。MACはデータ送信時に生成する。その意味としては送信データを要約したような情報と考えればよい。送信者は送信データにMACを付与してデータを送出する。次に、そのデータを受信した者は、まず自分が受信したデータに対して送信者と同じ手順で独自のMACを生成する。その独自のMACと、送信者が付与したMACを比較して、両者が一致すれば通信中の改ざんはなかったと判断できる、という原理である。 なお、本稿では、MA
fladdict.net blog: MIXIを使った、トラフィックの個人追跡システム
というのが可能だと考え付いて、ちょっと愕然とした。 自分のサイトに、隠しiframeでMIXIの自ページを読み込ませておくの。 そうすると、自分のサイトを訪れたログイン中のMIXI会員は、足跡がついちゃうの。あとは定期的に足跡キャッシュする。誰がウチのサイトを見てるかバレバレ（注：実装してないよ）。 一見、アホネタだけど。これ凄いシリアスな問題だよな。だってさ、エロサイトとかにそういう仕組みがあったら、最悪の場合一瞬で個人情報特定されるぜ？サイトのクッキーと、MIXIのアカウントとかが結びつけられた日には、何がおこるかわかったもんじゃないですよ。 １００万超過の巨大コミュニティとなった今、MIXIの持っていた知り合いとの人間関係を担保とした安全性ってのは、もうとっくに崩壊してる。さらにザバサーチのようにネット上に分散する情報をかき集めれば、かなりの精度で個人情報が筒抜けになる危険性も増して
セキュリティレベルの高いサイトを構築する 22 カ条 :: Drk7jp:
最近、何処の会社でもセキュリティに関してうるさく言われているかと思います。自分としても今まで気を遣ってきていたつもりではあります。しかしながら、 なぜSSL利用をケチるのか：IT Pro SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 安全なWebサイト設計の注意点 を読んでみて、お恥ずかしい限りですが勘違いしていた部分もありました。実際、Amazon とか Yahoo! のログイン画面を見ても、デフォルトが http によるアクセスになっていたりして、メジャーどころでも最新の注意が払われている訳ではないのだなぁ〜と思ったり・・・。本当は全ページ SSL が理想とは知りつつも、SSL の処理負荷の高さ故に、ついついケチったページ遷移にしまうからなのでしょう。。。自分含めて。 自分への情報もかねて、上記ページに記載されている、31箇条の鉄則と最近の事情を加
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
