UDIDが使えなくなりそうなので、UIIDを使えるようにしました
■2012/11/11追記 iOS 6より[[UIDevice currentDevice] identifierForVendor]というAPIがAppleより提供され、よりプライバシーに配慮した上により安全な方法で自分の開発したアプリケーションを利用するユーザーを個別に認証することが可能になりました。それに伴い拙作のライブラリもidentifierForVendorが利用可能であればこちらを利用するように修正いたしました。今後はこのidentifierForVendor（または広告APIなどを作る場合であれば[[UIDevice sharedManager] advertisingIdentifier]）が個体認識の主流になっていくと思われます。identifierForVendorとadvertisingIdentifierの仕様まとめは http://stackoverflow.c
春山 征吾のくけー : 2011/08/21 携帯端末における「MACアドレスで認証」の問題点 - livedoor Blog（ブログ）
https://www.unixuser.org/~haruyama/blog/ に移転しました http://wiki.livedoor.jp/haruyama_seigo/d/FrontPage @haruyama タイトルが思いつかないときはそのときかかってた曲をタイトルにしています. 2011/08/21 一日家でだらだらした. yebo blog: iOS 5で、開発者がUDIDにアクセスすることを禁止 で UDID 利用禁止への対策として MACアドレスをMD5にかけて利用というものがあげられている. そもそも端末識別/認証すべきではないという話で, アプリごとにUUIDを生成して利用すればそのUUIDでは名寄せできなくなってよい. しかし, 広告プロバイダなどの立場では楽に名寄せができないのが嫌, ということで騒ぎになっている. UDIDが利用できなくなるリスクは考慮しておく
UDIDに依存する人々とたしなめる人々
まとめ NTT docomo IMEI垂れ流し問題（19日から20日午前6時まで） 2011年10月19日、docomoのスマートフォンにプリインストールのメディアプレーヤーがHTTPヘッダでIMEIタレ流しという困った仕様になっていることが判明した件についてまとめました。（19日から20日午前6時まで） 音楽・動画 | サービス・機能 | NTTドコモ http://www.nttdocomo.co.jp/service/developer/smart_phone/service_lineup/music_movie/index.html （10月20日頃更新され、通常のHTTP通信では送らず、PlayReady®のライセンス取得の際にだけ送り、ユーザの許諾もその都度得ると訂正。） 上記ページ、更新前のWeb魚拓： http://megalodon.jp/2011-1019-1834..
なぜiOSでUDIDが必要とされていたのか、メモ - snippets from shinichitomita’s journal
iOSやその開発事情に詳しいと言える状態にはないので、調査を兼ねて書く。 Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID – TechCrunch http://wirelesswire.jp/Watching_World/201108221335.html 上記の「iOSでUDIDの利用が禁止」というニュースを聞いた時、正直TL上にこんなにいっぱい反応が貼り出されるとは思っていなかった。さすがにUDIDをいじるのはまずいよね、っていうコンセンサスは開発者の間では常識的部類に入ってくるのだろうと楽観的に捉えていたのかもしれない。 以下、なぜUDIDがそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。 アプリケーションのサーバとのセッション保持 い
UDID及び類似方式による行動ターゲッティング広告のセキュリティ実験に関する呼びかけ
Hiromitsu Takagi @HiromitsuTakagi いろいろヤバい。ネタのストックは大量にあるが、ウイルス罪やら番号制度やらが優先で、書いていく時間が足りてない。もうTwitterで先出していくしか。 Hiromitsu Takagi @HiromitsuTakagi UDIDやスーパークッキー同等の問題は英語圏でいずれ必ず問題視されて路線変更に至るが、日本の人たちがそれに取り残されてしまって、後で困ったことになることが国家的損失。そうならないよう早め早めに啓蒙していくことが重要であるところ。残念ながら政府の取組みは極めてお粗末で、… Hiromitsu Takagi @HiromitsuTakagi …政府の取組みは極めてお粗末で、セキュリティについては2003年ごろから積極的に取り組まれるようになったが、データプライバシーはそれとは全くの別物とみなされていて、政策課題に
PHP5.3.7のcrypt関数に致命的な脆弱性(Bug #55439)
PHP5.3.7のcrypt関数には致命的な脆弱性があります。最悪のケースでは、任意のパスワードでログインできてしまうという事態が発生します。該当する利用者は、至急、後述する回避策を実施することを推奨します。 概要 PHPのcrypt関数は、ソルト付きハッシュ値を簡単に求めることができます（公式リファレンス）。crypt関数のハッシュアルゴリズムとしてMD5を指定した場合、ソルトのみが出力され、ハッシュ値が空になります。これは、crypt関数の結果がソルトのみに依存し、パスワードには影響されないことを意味し、crypt関数を認証に用いている場合、任意のパスワードでログインに成功する可能性があります。 影響を受けるアプリケーション crypt関数を用い、ハッシュアルゴリズムとしてMD5を指定しているアプリケーション。 環境にも依存しますが、デフォルトがMD5の場合もあります。筆者のテスト環境
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
