On Wed, Jan 23, 2013 at 01:20:07PM +0100, . wrote:
CAPTCHAS are a defense in depth that reduce the number of spam
incidents to a number manageable by humans.
No, they do not. If you had actually bothered to read the links that
I provided, or simply to pay attention over the last several
On Thu, Jan 24, 2013 at 5:48 AM, Rich Kulawiec r...@gsp.org wrote:
On Wed, Jan 23, 2013 at 01:20:07PM +0100, . wrote:
CAPTCHAS are a defense in depth that reduce the number of spam
incidents to a number manageable by humans.
No, they do not. If you had actually bothered to read the links
On 13-01-24 13:52, George Herbert wrote:
It's true that relying on the laziness of attackers is statistically
useful, but as soon as one becomes an interesting enough target that
the professionals aim, then professional grade tools (which walz
through captchas more effectively than normal
On Thu, Jan 24, 2013 at 04:43:47PM -0500, Jean-Francois Mezei wrote:
It is better to have a tent with holes in the screen door than no screen
door. If the damaged screen door still prevents 90% of mosquitoes from
getting in, it does let you chase down and kill those that do get in.
I get this
On Thu, Jan 24, 2013 at 8:48 AM, Rich Kulawiec r...@gsp.org wrote:
(Yes, yes, I'm well aware that many people will claim that *their* captchas
work. They're wrong, of course: their captchas are just as worthless
as everyone else's. They simply haven't been competently attacked yet.
And
On 1/23/13, Rich Kulawiec r...@gsp.org wrote:
On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote:
Once again: captchas have zero security value. They either defend
(a) resources worth attacking or (b) resources not worth attacking. If
it's (a) then they can and will be defeated as
On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote:
that sort of abuse is likely need to be protected against
via a captcha challenge as well,
Once again: captchas have zero security value. They either defend
(a) resources worth attacking or (b) resources not worth attacking. If
On 23 January 2013 09:45, Rich Kulawiec r...@gsp.org wrote:
On Mon, Jan 21, 2013 at 02:23:53AM -0600, Jimmy Hess wrote:
that sort of abuse is likely need to be protected against
via a captcha challenge as well,
Once again: captchas have zero security value. They either defend
(a)
On Mon, 21 Jan 2013 23:23:16 -0500, Jean-Francois Mezei said:
This article may be of interest:
http://arstechnica.com/security/2013/01/canadian-student-expelled-for-playing-security-white-hat/
Basically, a Montreal student, developping mobile software to interface
with schools system found
On 1/21/13, Matt Palmer mpal...@hezmatt.org wrote:
Nonce on the server is a scalability hazard (as previously discussed). You
It's not really a scalability hazard. Not if its purpose is to
protect a data driven operation, or the sending of an e-mail; in
reality, that sort of abuse is
On 21 January 2013 07:19, Matt Palmer mpal...@hezmatt.org wrote:
...
If the form is submitted without the correct POST value, if their IP
address changed, or after too many seconds since the timestamp,
then redisplay the form to the user, with a request for them to
visually inspect and
On 21 January 2013 09:26, . oscar.vi...@gmail.com wrote:
On 21 January 2013 07:19, Matt Palmer mpal...@hezmatt.org wrote:
...
If the form is submitted without the correct POST value, if their IP
address changed, or after too many seconds since the timestamp,
then redisplay the form to the
--- jfmezei_na...@vaxination.ca wrote:
From: Jean-Francois Mezei jfmezei_na...@vaxination.ca
Either way, you still need to have either a cookie or a hidden form [...]
But ONLY when needing to do a transaction. As I originally mentioned
why
This article may be of interest:
http://arstechnica.com/security/2013/01/canadian-student-expelled-for-playing-security-white-hat/
Basically, a Montreal student, developping mobile software to interface
with schools system found a bug. Reported it. And when he tested to see
if the bug had been
On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote:
On Jan 18, 2013, at 7:52 PM, Matt Palmer mpal...@hezmatt.org wrote:
On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:
On 17 January 2013 23:38, Matt Palmer mpal...@hezmatt.org wrote:
..
By the way, if anyone *does* know of
On Jan 20, 2013, at 11:51 AM, Matt Palmer mpal...@hezmatt.org wrote:
On Sat, Jan 19, 2013 at 03:54:37PM -0800, George Herbert wrote:
On Jan 18, 2013, at 7:52 PM, Matt Palmer mpal...@hezmatt.org wrote:
Storing any state server-side is a really bad idea for scalability and
reliability.
?
On Sat, Jan 19, 2013 at 06:33:33PM -0600, Jimmy Hess wrote:
On 1/18/13, Matt Palmer mpal...@hezmatt.org wrote:
Primarily abuse prevention. If I can get a few thousand people to do
something resource-heavy (or otherwise abusive, such as send an e-mail
somewhere) within a short period of
On 13-01-21 01:19, Matt Palmer wrote:
Things that require me to worry (more) about scalability are out, as are
things that annoy a larger percentage of my userbase than cookies (at least
with cookies, I can say you're not accepting cookies, please turn them on,
whereas with randomly
On Thu, Jan 17, 2013 at 02:55:59PM -0800, Scott Weeks wrote:
--- mpal...@hezmatt.org wrote: ---
From: Matt Palmer mpal...@hezmatt.org
[Cookies on stat.ripe.net]
On Wed, Jan 16, 2013 at 11:36:25AM -0800, Shrdlu wrote:
The cookie stays around for a YEAR (if I let it), and has the
On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:
On 17 January 2013 23:38, Matt Palmer mpal...@hezmatt.org wrote:
..
By the way, if anyone *does* know of a good and reliable way to prevent CSRF
without the need for any cookies or persistent server-side session state,
I'd love to know
On Jan 18, 2013, at 7:52 PM, Matt Palmer mpal...@hezmatt.org wrote:
On Fri, Jan 18, 2013 at 09:41:41AM +0100, . wrote:
On 17 January 2013 23:38, Matt Palmer mpal...@hezmatt.org wrote:
..
By the way, if anyone *does* know of a good and reliable way to prevent CSRF
without the need for
On 1/18/13, Matt Palmer mpal...@hezmatt.org wrote:
Primarily abuse prevention. If I can get a few thousand people to do
something resource-heavy (or otherwise abusive, such as send an e-mail
somewhere) within a short period of time, I can conscript a whole army of
unwitting accomplices into
On 17 January 2013 23:38, Matt Palmer mpal...@hezmatt.org wrote:
..
By the way, if anyone *does* know of a good and reliable way to prevent CSRF
without the need for any cookies or persistent server-side session state,
I'd love to know how. Ten minutes with Google hasn't provided any useful
On 1/16/13 8:36 PM, Shrdlu wrote:
On 1/16/2013 9:40 AM, john wrote:
I took a look at this site and unfortunately the use of cookies is very
ingrained into the code. Removing the requirement breaks all
functionality of www.ris.ripe.net and changing the functionality would
require a rewrite
[Cookies on stat.ripe.net]
On Wed, Jan 16, 2013 at 11:36:25AM -0800, Shrdlu wrote:
The cookie stays around for a YEAR (if I let it), and has the
following stuff:
Name: stat-csrftoken
Content: 7f12a95b8e274ab940287407a14fc348
[...]
To your credit, you only ask once, but you ought to ask
--- mpal...@hezmatt.org wrote: ---
From: Matt Palmer mpal...@hezmatt.org
[Cookies on stat.ripe.net]
On Wed, Jan 16, 2013 at 11:36:25AM -0800, Shrdlu wrote:
The cookie stays around for a YEAR (if I let it), and has the
following stuff:
CSRF protection is one of the few valid uses of a
On 1/11/13 8:28 PM, Scott Weeks wrote:
--- andree+na...@toonk.nl wrote:
From: Andree Toonk andree+na...@toonk.nl
Here's some more data showing an announcement for
150.182.208.0/20 originated by 26347
--- jb...@ripe.net wrote:
From: john jb...@ripe.net
- On 1/11/13 8:28 PM, Scott Weeks wrote: -
RIPE needs to fix on their web site:
Please turn on the cookies on your browser to view this site.
It doesn't have to be this way...
-
I took a look at
On 1/16/2013 9:40 AM, john wrote:
I took a look at this site and unfortunately the use of cookies is very
ingrained into the code. Removing the requirement breaks all
functionality of www.ris.ripe.net and changing the functionality would
require a rewrite of the site.
Sooner or later, you'll
Not sure how widespread their leakage may be, but Dreamhost just
hijacked one of my prefixes...
Possible Prefix Hijack (Code: 10)
Your prefix:
Jeff,
We are not announcing the prefix in question nor do we peer with AS42861.
--
Best Regards,
Kenneth McRae
*Director, Network Operations*
kenneth.mc...@dreamhost.com
Ph: 818-447-2589
www.dreamhost.com
On Fri, Jan 11, 2013 at 7:23 AM, Jeff Kell jeff-k...@utc.edu wrote:
Not sure how
Robtex would beg to differ... you show peered with AS42861, perhaps
someone (else) is looping their advertisements?
_R_egistered
_O_ther side
_B_GP visible Peer
OB AS174 COGENT /PSI
B AS4323 TWTC Autonomous system for tw telecom .
B AS4826 VOCUS-BACKBONE-AS Vocus Connect
Sounds like someone in Russia is having some fun with as-path prepending
and prefix hijacking.
On Fri, 11 Jan 2013, Kenneth McRae wrote:
Jeff,
We are not announcing the prefix in question nor do we peer with AS42861.
--
Best Regards,
Kenneth McRae
*Director, Network Operations*
Just checked all BGP speakers again and I show no peering with AS42861.
On Fri, Jan 11, 2013 at 7:49 AM, Jeff Kell jeff-k...@utc.edu wrote:
Robtex would beg to differ... you show peered with AS42861, perhaps
someone (else) is looping their advertisements?
*R*egistered
*O*ther side
*B*GP
That would be my guess. We have had some issues with this in the past with
operators from China and Russia.
On Fri, Jan 11, 2013 at 7:51 AM, Jon Lewis jle...@lewis.org wrote:
Sounds like someone in Russia is having some fun with as-path prepending
and prefix hijacking.
On Fri, 11 Jan 2013,
Here at/as AS5580 I no longer see it announced as a /20, only your own /18:
#sh ip bgp routes 150.182.192.0 255.255.192.0 longer-prefixes
Number of BGP Routes matching display condition : 4
Searching for matching routes, use ^C to quit...
Status A:AGGREGATE B:BEST b:NOT-INSTALLED-BEST
Hi,
Here's a quick summary of what we saw at BGPMon.net.
At 2013-01-11 14:14:13 we saw announcements (seemingly) originated by
26347, for prefixes normally announced by other ASn's (origin change /
hijack).
This seems to have affected 112 prefixes for 110 ASn's [1], including
Rogers, Tata,
Jeff:
150.182.208.0/20 is not visible from AS702 in Germany.
150.182.192.0/18 path is 702 701 209 26827 14209
Tony
On 11 January 2013 15:23, Jeff Kell jeff-k...@utc.edu wrote:
Not sure how widespread their leakage may be, but Dreamhost just
hijacked one of my prefixes...
Thanks for that info Andree. The only valid peer I see on the list would
be HE. We do not peer with any of the others listed.
Kenneth
On Fri, Jan 11, 2013 at 8:46 AM, Andree Toonk andree+na...@toonk.nl wrote:
Hi,
Here's a quick summary of what we saw at BGPMon.net.
At 2013-01-11 14:14:13
Hi Kenneth,
.-- My secret spy satellite informs me that at 2013-01-11 8:54 AM
Kenneth McRae wrote:
Thanks for that info Andree. The only valid peer I see on the list
would be HE. We do not peer with any of the others listed.
Could it be these ASns receive your routes via an IX route-server?
Hi all,
Atrato / 5580 here.
We don't have direct peering with AS26347, although we learn the AS26347
prefixes through the 206.223.143.253 (AS 19996) routeserver in LAX.
So in a sense we are peering :-)
Kind regards,
Job
On Jan 11, 2013, at 7:31 PM, Andree Toonk andree+na...@toonk.nl
Yes, now that is possible (just no direct peering). So that takes me back
to my original statement about not announcing the 150.182.208.0/20 prefix
to begin with.
Kenneth
On Fri, Jan 11, 2013 at 10:31 AM, Andree Toonk andree+na...@toonk.nlwrote:
Hi Kenneth,
.-- My secret spy satellite
.-- My secret spy satellite informs me that at 2013-01-11 10:44 AM
Kenneth McRae wrote:
Yes, now that is possible (just no direct peering). So that takes me
back to my original statement about not announcing the 150.182.208.0/20
http://150.182.208.0/20 prefix to begin with.
Here's some more
--- andree+na...@toonk.nl wrote:
From: Andree Toonk andree+na...@toonk.nl
Here's some more data showing an announcement for
150.182.208.0/20 originated by 26347
44 matches
Mail list logo
