What's to stop the bot from grabbing the token from the home page and
using it in its attack? The token has to be something the
bot can't readily read, e.g., captcha.
On Aug 18, 2007, at 10:11 AM, Carl Johnstone wrote:
Bill Moseley wrote:
Unfortunately, often want to have a login form on
What's to stop the bot from grabbing the token from the home page and
using it in its attack? The token has to be something the
bot can't readily read, e.g., captcha.
Bill said:
I have the ability to turn on form tokens on my forms, so to be able
to post to a form you have to first fetch
He is referring to reposting of forms that are arrived at via the
back button, e.g.,
breaking the cycle submit form - click back button - submit form -
etc.
The use case is for single use forms not for security. It wouldn't
do anything to
prevent a bot from scraping the HTML for that
Bill Moseley wrote:
Unfortunately, often want to have a login form on the home page and
that page is typically static -- so can't use my token in that
situation.
How about using a variation of the token system. You have a token that's
valid for any request that you change fairly
On Fri, Aug 17, 2007 at 09:48:33PM -0500, Jonathan Rockway wrote:
Bill Moseley wrote:
What's the status of the Cache plugin(s) wrt. backends?
I want to be able to swap between FastMmap and Memcached via a config
option
As per the docs:
# configure a backend or use a store plugin
I'm looking for ideas on how to implement a way to detect and block
dictionary attacks. This is not a question of how to implement strong
passwords, but rather the act of limiting logins when too many failed
passwords have been attempted in some period of time.
I was just wondering why can't
Antano Solar wrote:
I was just wondering why can't the form fields for username and
password be changed after every x attempts. And the post data checked
for the new fields.
This is a good approach, and is automatic if you use the FormCanary or
RequestToken plugins.
Regards,
Jonathan Rockway
Anyone doing something like this already? Suggestions? Caveats?
You'll almost certainly have to log it per-IP address rather than an a
cookie or session or anything like that. Any real password-cracking bot is
unlikely to honour your cookies or session identifiers.
Which in return means
On Fri, Aug 17, 2007 at 03:56:23PM +0100, Carl Johnstone wrote:
Anyone doing something like this already? Suggestions? Caveats?
You'll almost certainly have to log it per-IP address rather than an a
cookie or session or anything like that. Any real password-cracking bot is
unlikely to
Bill Moseley [EMAIL PROTECTED] wrote on 08/17/2007 10:32:36 AM:
On Fri, Aug 17, 2007 at 03:56:23PM +0100, Carl Johnstone wrote:
Anyone doing something like this already? Suggestions? Caveats?
You'll almost certainly have to log it per-IP address rather than an a
cookie or
Well, that would be every environment where Catalyst runs. If you
want to do something fancy, I'd suggest looking at lingerd, a C daemon
written to take TCP connections handed off from mod_perl. It would
require some C-level hacking, but I expect you could alter it for this
purpose.
Lingerd
Also considered issuing a redirect to a simple server that will delay
the number of failed attempts seconds before redirecting back to the
login page. Any smart attacker would get clued about this an not
follow that redirect. Fun anyways, though. ;)
As I just said in the other
On Fri, Aug 17, 2007 at 11:49:42AM -0400, Perrin Harkins wrote:
On 8/17/07, Carl Johnstone [EMAIL PROTECTED] wrote:
You'll almost certainly have to log it per-IP address rather than an a
cookie or session or anything like that. Any real password-cracking bot is
unlikely to honour your
On Aug 17, 2007, at 10:56 AM, Carl Johnstone wrote:
Anyone doing something like this already? Suggestions? Caveats?
You'll almost certainly have to log it per-IP address rather than
an a cookie or session or anything like that. Any real password-
cracking bot is unlikely to honour your
On 8/17/07, Bill Moseley [EMAIL PROTECTED] wrote:
I missed something along the way in this thread. Cookies? Is that to
block a specific client?
Yes, as opposed to an IP that could be a proxy.
I'm just thinking of blocking specific logins when too many failed
logins are attempted.
That
On Fri, Aug 17, 2007 at 02:12:21PM -0400, Jason Kohles wrote:
Instead of delaying the response, one possibility is to send a
complete response without a login form, just a note that says 'too
many attempts, try again in X seconds', possibly with a refresh to
reload the page once the
I like the idea of the captcha after a few failed requests. Although,
if it's a real person having problems logging in then the addition of
the captcha just make it that much more likely that they will not be
able to login. Kind of amazing how often I fail the captcha.
Plus, captcha's are not
On Fri, Aug 17, 2007 at 02:33:21PM -0400, Perrin Harkins wrote:
I'm just thinking of blocking specific logins when too many failed
logins are attempted.
That works if they keep hitting the same login with different
passwords. Are you concerned about them trying many logins with a
common
Bill Moseley wrote:
What's the status of the Cache plugin(s) wrt. backends?
I want to be able to swap between FastMmap and Memcached via a config
option
As per the docs:
# configure a backend or use a store plugin
__PACKAGE__-config-{cache}{backend} = {
class =
I'm looking for ideas on how to implement a way to detect and block
dictionary attacks. This is not a question of how to implement strong
passwords, but rather the act of limiting logins when too many failed
passwords have been attempted in some period of time.
I also want to do this regardless
On Aug 16, 2007, at 10:13 AM, Bill Moseley wrote:
I'm looking for ideas on how to implement a way to detect and block
dictionary attacks. This is not a question of how to implement strong
passwords, but rather the act of limiting logins when too many failed
passwords have been attempted in
On 8/16/07, Bill Moseley [EMAIL PROTECTED] wrote:
I'm looking for ideas on how to implement a way to detect and block
dictionary attacks. This is not a question of how to implement strong
passwords, but rather the act of limiting logins when too many failed
passwords have been attempted in
22 matches
Mail list logo
