Captchaエラーへの対処・開発

963 views
Skip to first unread message

吉積礼敏

unread,
May 15, 2012, 10:10:23 AM5/15/12
to google-app-...@googlegroups.com
吉積と申します。

UserServiceで認証をかけるアプリがあるのですが、たまーにCaptchaExceptionが出てしまいます。
GoogleAppsドメイン(有料)前提です。
現象としては、同じユーザアカウントについてUserSercieでのsetCredentialで、
GAE上ではCaptchaエラーになるのですが、同じ状況で、ローカルのEclipse環境からは通ってしまいます。

上記の原因とか同じ状況になられたことがある方はいらっしゃいますでしょうか?
また、開発環境(ローカル)でCaptchaエラーに対処するためのコードをテストしたいと思った時に、
簡易にエラーを発生させる方法をどなたかご存知では無いでしょうか?
取り敢えず30回くらいパスワード間違えてみましたが、発生しません。。。

また、もしご存知でしたら、
・ユーザに発生したCaptchaExceptionを管理者権限でリセットすることは可能か?
・上記をAPIでリセット可能か?

についてもご存知でしたら教えて下さい。
因みにSSOは実施済みの前提ですが、GoogleApps側で持っている認証情報で認証したい、というニーズです。

よろしくお願い致します。

--
★★★★★★★★★★★★★★★★★★★★★★★★
※※※ Googleトータルソリューション企業 吉積情報 ※※※
※※※ eco+リクルート→『スマセル』始めました ※※※
※※※ 無料ダイビング学科講習サイト  『シーパス』好評運用中※※※

吉積情報株式会社
代表取締役 吉積 礼敏 <ayat...@yoshidumi.co.jp>
携帯:090-1732-1848
住所:〒104-0061 東京都中央区銀座2-14-7 銀座OMビル2F
電話:03-6228-4451
FAX :03-5843-1690
HP :http://www.yoshidumi.com

Shinichi Ogawa

unread,
May 15, 2012, 1:08:42 PM5/15/12
to google-app-...@googlegroups.com
吉積さん

ここでいうUserServiceは、Google App Engine SDKに含まれるUserServiceのことではなく
GData API用のLibrary関連に含まれるServiceクラスのsetCredentialメソッドの話でしょうか?
もし「Client Login認証」を使う話であればCaptchaExceptionが出るのは仕様通りです。

Client Login認証は使うべきではないとされていて、
GData APIを利用するために必要な認可ではOAuth2かOAuth1を使う方法が推奨されています。
認可ではなく認証が目的の場合でも、
userinfo API(*)を使えばOAuth2で認可しつつユーザ情報を取得することで代用できるかもしれません。

* 正式名称は忘れましたが、scope: https://www.googleapis.com/oauth2/v2/userinfo に対応するAPI

2012/5/15 吉積礼敏 <ayat...@yoshidumi.co.jp>:
> --
> このメールは Google グループのグループ「Google-App-Engine-Japan」の登録者に送られています。
> このグループに投稿するには、google-app-...@googlegroups.com にメールを送信してください。
> このグループから退会するには、google-app-engine...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/google-app-engine-japan?hl=ja からこのグループにアクセスしてください。
>

塩瀬悠樹

unread,
May 25, 2012, 6:02:23 AM5/25/12
to google-app-...@googlegroups.com
小川様

返信、間が開いてしまいすいません。
吉積にかわりまして、私の方から説明します。

ここで説明しているUserServiceはGData APIのUserService#setUserCredentials() で間違いないです。
そして、説明が分かりにくくて申し訳なかったのですが、弊社のアプリケーショはSSOを提供する都合上、ユーザのパスワード認証をプロキシする事がそもそもの目的なので、OAuth認証は目的に合わないと考えてます。

そこで再度質問なのですが、CaptchaRequiredExceptionが出た時、
 ・Appsの特権管理者がCaptchaRequiredの状態をクリアする方法はありますでしょうか?
 ・CaptchaRequiredの状態をクリアする何らかのAPIは存在しますでしょうか?

補足ではありますが、CaptchaRequiredの状態は、setUserCredentialsに正しいユーザ名とパスワードを渡して
プログラムで800回以上ループしてリクエストを投げると、発生するようです。

2012年5月16日 2:08 Shinichi Ogawa <shin1...@gmail.com>:
--
*§*―――――*§*―――――*§*―――――*§*―――――
Googleトータルソリューション企業 吉積情報株式会社
東京都中央区銀座2-14-7 銀座OMビル 3F
TEL:03-6228-4451
FAX:03-5843-1690

Shinichiroh Takezaki [Virtual Technology]

unread,
May 25, 2012, 8:23:48 AM5/25/12
to google-app-...@googlegroups.com
竹嵜と申します。
横から失礼いたします。

私が試したときは、認証が成功しさえすれば何回でも実行させることができたのですが、最近では800回程度の連続した認証要求でも(悪質な機械による攻撃だとみなされて)CaptchaRequiredがでるようになっているのかもしれません。これが出る条件はよくわかっておらず、怪しいリクエストだと思われたら出るぐらいに考えておいた方がいいと思います。実際にDisplayUnlockCaptchaをやると以下の説明がでてきます。

この追加の確認手順が表示されているのは、最近、ご使用のアカウントへの不審なログイン試行が検出されたためです。あなたが携帯端末やアプリケーションを使用してログインしようとした可能性もありますが、これらの試みがあなたが実際に行ったものであることを確認する必要があります。」

CaptchaRequiredは、要は、総当たり攻撃や辞書攻撃といった機械的なアタックから守るために出ているのであって、これが出た以上は、「人間が入力していること」を証明してあげる必要があります。
(裏ではクラッカーとの相当な「いたちごっこ」が続いているのでしょう)
実際に、http://www.google.com/accounts/DisplayUnlockCaptcha で、歪んだ文字を入力してパスしたら、UNLOCKされます。

詳しい解除方法は以下が参考になります。

これがもし機械的に解除できるのであれば、クラッカーはそこを突いてくる可能性もあるわけで、CAPCHAは無意味になってしまいます。(というかバグです)
よって、CaptchaRequiredの状態をクリアする何らかのAPIは存在しないと思われますので、小川さんのおっしゃるように、OAuth認証を使うことをおすすめします。


2012年5月25日 19:02 塩瀬悠樹 <shi...@yoshidumi.co.jp>:

吉積礼敏

unread,
May 26, 2012, 3:44:27 AM5/26/12
to google-app-...@googlegroups.com
竹嵜様

ご意見、ありがとうございます。最初の質問投稿しました吉積です。

もちろんCaptchaの必要性も理解はしているつもりですが、

・一般ユーザにはSSOさせているので、ユーザIDをGoogleとは違うものを入れさせている中、Capthca解除時には入れさせると言う運用は困難。
・GoogleAppsの前提で、管理者が何らか出来ても良いのでは無いか。
・Google側のパスワードを使ってSSOの認証をしたいと言う要件がOAUTHでは実現出来ない。

ことからの質問投稿になります。
例えば管理者のOAUTH認証が入った状態から一般ユーザのCapthcaを解除させることが出来る。
というのはバグでも無くセキュリティホールでも無く対応可能な一案では無いでしょうか?

よろしくお願い致します。

2012年5月25日 21:23 Shinichiroh Takezaki [Virtual Technology]
<take...@virtual-tech.net>:

--
★★★★★★★★★★★★★★★★★★★★★★★★
※※※ GoogleApps販売・導入サポートをしております ※※※
※※※ ダイブネットもよろしくお願いします!http://www.divenet.jp ※※※

Shinichiroh Takezaki [Virtual Technology]

unread,
May 26, 2012, 2:54:53 PM5/26/12
to google-app-...@googlegroups.com
竹嵜です。

私の考え方を述べさせていただきます。(私はセキュリティの専門家ではなく間違いがあるかもしれませんので、その点はご容赦ください)

>管理者のOAUTH認証が入った状態から一般ユーザのCapthcaを解除させる
前述したように、「Capthcaを解除させる=本人であることを確認する」という行為になることから、管理者であっても代行(悪く言えば成り済まし)はできないと思われます。Capthca要求状態になっているのを解除するにはパスワードリセットが必要だと思われます。もちろん、管理者にはユーザのパスワード変更やリセットが可能ですが、これは代行ではなく管理者の権限として実行されるものです。

(ただし、管理者であってもユーザのパスワード参照の権限は与えられません。パスワード参照はGoogleに限った話ではなく個人情報保護という観点でNGとなるようです。また、新しいパスワードを設定することで管理者がログイン可能になりますが、これは管理者が所有しているということであって、この状態(同じパスワード)でユーザに使わせるとアカウントを共有している状態となってしまい、これはこれでセキュリティ上問題があります。ユーザには新たにパスワードを設定してもらったうえで使ってもらうべきでしょう。)

さて、ProvisionigAPIのディスカッションを探していたら参考になりそうな投稿がありました。


I'm currently working on an internal web application (and a script or two) to allow our employees to change their password for both Google Apps and our own internal services (which rely on LDAP for authentication -- so each user has one common password across everything). The user will choose their new password from this web app, and the app will, in turn, change the password in Google Apps and other services.」

独自サービスからGoogle Appsのアカウントのパスワードを更新したいという話ですが、OAuth2.0でProvisioning APIを使うのがおすすめだそうです。デスクトップアプリで使う場合のサンプルもあります。(ちなみにパスワード変更ができるのは独自ドメインだけだそうです)

Refer to this sample in Python that uses OAuth 2.0 for a desktop application (not a web application). In this application, user is given the authorization URL to visit. This article explains steps for using OAuth with the Provisioning API.

また、2-legged OAuthでは、Provisioning APIのアクセスはできないようなので、Client Loginもたぶんできないと思います。

There are no plans for now to give read/write access with 2-legged OAuth for the Provisioning API. This is for the better security of the domain data.

最後に、Client Loginのようなパスワードを保存するような仕組みではセキュリティ上のいろいろな制約があります。認証においては、セキュリティの理由があって、敢えて制約されている場合がありますので、「あってもよさそうな便利機能」が見つからない場合は、セキュリティ上の理由と諦めるしかないケースも多いかと思います。

繰り返しになりますが、OAuth 2.0で解決できないか、もう一度トライされることをお勧めします。

2012年5月26日 16:44 吉積礼敏 <ayat...@yoshidumi.com>:



--
 _/ 有限会社バーチャルテクノロジー 竹嵜 伸一郎
 _/  Virtual Technology, Ready to Cloud
 _/ http://www.virtual-tech.net/

吉積礼敏

unread,
May 27, 2012, 7:33:51 PM5/27/12
to google-app-...@googlegroups.com
竹嵜様

吉積です。ご意見本当にありがとうございます。

要望をちゃんと伝えきれていない気がします。

要件としては、パスワードの更新では無く、「認証」だけです。
また、私の理解ではCaptcha解除にはパスワードの更新は不要です。

ユーザ名とパスワードの一致性をAPI経由で確認する、ということを実現したいのですが。OAUTHを使って、パスワードの一致性をAPIで確認する(認証)機能は無いと思っています。

管理者が出来ないのがセキュリティ上の理由であると言うことなら、まぁ仕方ないのかも知れませんが。。運用性は相当低いと言わざるを得ないですよね。
管理者はユーザの停止から削除まで出来るのに、セキュリティ上Captcha解除出来ないと言うのは私には正直納得感がありません。

よろしくお願い致します。

2012年5月27日 3:54 Shinichiroh Takezaki [Virtual Technology]

Shinichiroh Takezaki [Virtual Technology]

unread,
May 27, 2012, 9:59:19 PM5/27/12
to google-app-...@googlegroups.com
竹嵜です。

要件はよくわかっていないのですが、Googleの認証が本当に必要かどうかは、よく検討する必要があるかと思います。

「認証」は本人確認を伴いますが、SSOで認証を実行している(本人確認が済んでいる)前提であれば、GoogleAppsでは必要ないはずと思っておりました。

ところで、userid/password方式では、「パスワードを知っている」をもって本人確認がなされます。
管理者がログイン可能な場合は、Aさんのパスワードを知っているときで、成り済ましをしているからに他なりません。(Google認証機能としては管理者ではなくAさんとして認識している)

CAPTCHAは認証機能の一部であり、本人が機械でないことを確かめるためにありますので、本人自身が実施することが前提になります。(管理者が解除できてしまうと本人が機械でないことを証明できないし本人確認にならない)

認証では管理者であってもユーザ本人とは区別されます。
そのうえで本人と同等の様々なことができる(認可)というのは設計上問題ありませんが、管理者がユーザを兼ねるような認証機能はまずいと思われます。


2012年5月28日 8:33 吉積礼敏 <ayat...@yoshidumi.com>:

吉積礼敏

unread,
May 28, 2012, 12:44:39 PM5/28/12
to google-app-...@googlegroups.com
竹嵜様

なるほど、Captchaが認証機能の一部であり、本人認証が必須と言う話なのですね。
私の理解では、マシンがアタックを試みることを弾くと言うことと認識してました。
なので、本人以外が保証してあげても良いのかなぁと思ったのですが。。

やりたかったのは、SSOアプリとして認証する際に、ユーザIDとパスワードの組合せをチェックする先として、GoogleApps側のユーザIDとパスワードで実施する。
ということです。他にも認証先は指定出来る中でのオプションとして、です。
余りおすすめのオプションではありませんが、ニーズがゼロでは無いです。

しかし、まぁセキュリティ上本人確認がCaptcha解除には必須であると言うことであれば、この機能は実現出来そうにない、ということになりそうです。

ちなみに、何らか別の方法で本人認証を行った上で、SSOで一度通してGoogleAppsにログインさせてしまうと、Captchaエラーが一時でなくはなるような挙動をしてます。
回避策としてはこれしか無いかなぁ、と思います。

よろしくお願い致します。

2012年5月28日 10:59 Shinichiroh Takezaki [Virtual Technology]

Takashi Matsuo

unread,
May 28, 2012, 1:05:38 PM5/28/12
to google-app-...@googlegroups.com
2012/5/29 吉積礼敏 <ayat...@yoshidumi.com>:

> 竹嵜様
>
> なるほど、Captchaが認証機能の一部であり、本人認証が必須と言う話なのですね。
> 私の理解では、マシンがアタックを試みることを弾くと言うことと認識してました。
> なので、本人以外が保証してあげても良いのかなぁと思ったのですが。。
>
> やりたかったのは、SSOアプリとして認証する際に、ユーザIDとパスワードの組合せをチェックする先として、GoogleApps側のユーザIDとパスワードで実施する。
> ということです。他にも認証先は指定出来る中でのオプションとして、です。
> 余りおすすめのオプションではありませんが、ニーズがゼロでは無いです。

SSO アプリ側でパスワードのハッシュを持っておけば良いんじゃないでしょうか。
それなら ClientLogin を使う必要はないかと思います。

そもそも ClientLogin は Deprecate されているので今後は使わない方が良いです。
参考:
http://googledevelopers.blogspot.jp/2012/04/changes-to-deprecation-policies-and-api.html
https://developers.google.com/accounts/docs/AuthForInstalledApps

もちろん Web App なら OAuth2.0 を、
Installed Application でも OAuth2.0 を、
今回のような SSO では、ClientLogin ではなく別の方法を使ってください。

-- matsuo

--
Takashi Matsuo | Developer Advocate | tma...@google.com

Shinichiroh Takezaki [Virtual Technology]

unread,
May 31, 2012, 3:04:37 PM5/31/12
to google-app-...@googlegroups.com
竹嵜です。

もしかしたら、これが使えるかもしれません。

Google Apps Password Sync (GAPS)

Whenever a user's Active Directory password is changed, GAPS pushes
the change to Google Apps immediately.

http://support.google.com/a/bin/answer.py?hl=en&answer=2611859

2012年5月29日 2:05 Takashi Matsuo <tma...@google.com>:

Reply all
Reply to author
Forward
0 new messages