Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
I would think it would be safer to block the site, or provide a warning dialog. (This is what I was expecting when I started reading the head post; I was bit surprised at the interventionism to actually go ahead and fix the site, maybe that would be a better default behavior). btw Regarding unadvertised SSL equivalents, I have noticed if you login to gmail, you get SSL for login, but then http for web mailer. However if you edit the URL after login to https, it appears to work ok over SSL also. Adam On Mon, Sep 19, 2005 at 04:20:07PM -0700, John Gilmore wrote: Perhaps the idea of automatically redirecting people to alternative pages goes a bit too far: 1. TrustBar will automatically download from our own server, periodically, a list of all of the unprotected login sites, including any alternate protected login pages we are aware of. By default, whenever a user accesses one of these unprotected pages, she will be automatically redirected to the alternate, protected login page. How convenient! So if I could hack your server, I could get all TrustBar users' accesses -- to any predefined set of pages on the Internet -- to be redirected to scam pages. A redirect to an untrustworthy page is just as easy as a redirect to a trustworthy page. The question is who you trust. BTW, TrustBar is an open-source project, so if some of you want to provide it to your customers, possibly customized (branded) etc., there is no licensing required. Also providing a handy platform for slightly modified versions, that will take their cues from a less trustworthy list of redirects. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Defending users of unprotected login pages with TrustBar 0.4.9.93
Dare I say that the best must not be the enemy of the good? --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 2005-09-20, Jerrold Leichter wrote:
One thing to consider is that an idiom like this solves an annoying problem.
Consider a linear search through an array:
for (i = 0; i lim; i++)
{ if (a[i] == target)
{ do something
break;
}
}
/*
* Did we get here because we matched or because we
* failed to match?
*/
No, we got here because we didn't know basic C usage. Come on
people, please stop creating these fake illustrations.
A real C programmer would have known that, if i == lim, there
was no match. This is so trivial it beggars belief that it
needs to be pointed out in a forum like this.
Personally, I sometimes use:
for (i = 0; i lim; i++)
{ if (a[i] == target)
goto found;
}
This draws shock and horror from some code readers, but I don't care. :-)
Note how much it looks like the exception-based code.
It only draws gasps from people who don't know C. The goto that
is famously considered harmful is not spelled goto in C, but
rather longjmp; it's not used all that often and does need
careful handling. The C goto statement is purely a local goto
and scares nobody who has grown up.
Greg
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Contactless payments and the security challenges
One issue I have not seen addressed in these contactless payment systems is the needs of people who carry multiple payment instruments. A simple example is a personal and a corporate credit card. Cheers - Bill - Bill Frantz| The first thing you need | Periwinkle (408)356-8506 | when using a perimeter | 16345 Englewood Ave www.pwpconsult.com | defense is a perimeter.| Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
| One thing to consider is that an idiom like this solves an annoying
problem.
| Consider a linear search through an array:
|
| for (i = 0; i lim; i++)
| { if (a[i] == target)
| { do something
| break;
| }
| }
| /*
| * Did we get here because we matched or because we
| * failed to match?
| */
|
| No, we got here because we didn't know basic C usage. Come on
| people, please stop creating these fake illustrations.
Oh, come on. This loop has a trivial increment and a trivial stopping
condition, for the purpose of illustration. But even here, it's not so
simple. Better style in general is to limit the loop variable's scope to the
loop:
for (int i = 0; i lim; i++)
{ }
Now i isn't accessible after the loop is done. My personal style has always
been to treat the loop variable as local to the loop, even when C didn't let
you declare it that way. There are exceptions - especially cases where you
traverse the same array in two consecutive loops, the second picking up where
the first ended - but I've generally found that to be a better style.
| A real C programmer would have known that, if i == lim, there
| was no match. This is so trivial it beggars belief that it
| needs to be pointed out in a forum like this.
|
| Personally, I sometimes use:
|
| for (i = 0; i lim; i++)
| { if (a[i] == target)
| goto found;
| }
|
| This draws shock and horror from some code readers, but I don't care. :-)
| Note how much it looks like the exception-based code.
|
| It only draws gasps from people who don't know C. The goto that
| is famously considered harmful is not spelled goto in C, but
| rather longjmp; it's not used all that often and does need
| careful handling. The C goto statement is purely a local goto
| and scares nobody who has grown up.
Nice to know we're all adults here :-)
-- Jerry
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Java: Helping the world build bigger idiots
On 9/20/05, Rich Salz [EMAIL PROTECTED] wrote: This is wandering way far afield of the list charter. In an effort to maintain some relevance, I'll point out that code reviews, and crypto programming, are rarely done, and arguably shouldn't, by programming wizards. If by that you mean, Program dumb: avoid tricky code, avoid odd usage, stick to the basics, I agree. Save your clever tricks for hobby code and the snippets you use to score hot chicks. Critical code, potentially dangerous code, and professional code should be written simply and with the idioms standard to the language. On a related note, I've worked a bit with avionics and embedded medical software. The certification requirements for those bits of critical code might be helpful for crypto programming. -- There are no bad teachers, only defective children. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Clips] Contactless payments and the security challenges
On 9/21/05, [EMAIL PROTECTED] (Nick Owen) wrote: Interesting question. I know that we can solve it on a application-enabled cell phone with public keys - each service has only swapped public keys so you can have any number. Can such a thing be done on an RFID card too? Bill Frantz wrote: One issue I have not seen addressed in these contactless payment systems is the needs of people who carry multiple payment instruments. A simple example is a personal and a corporate credit card. It seems to me a use case is paying for a meal. The cost may be personal: I've taken my wife out to dinner and a show; or corporate: I'm on a business trip. I need to specify which payment instrument is to be used, and not have it automatically sniffed out of my wallet or cell phone. If payment means putting the token next to the reader, i.e. a read distance of only a few centimeters, then there should be no problem. If payment happens at RFID distances, then I'll need Faraday shields for the tokens, eliminating most of the value of contactless payments. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
