Board index » delphi » Encrypting a password string.

Henrick Hellstr?

Delphi Developer
Sat, 19 Feb 2005 22:59:04 GMT

Encrypting a password string.

Quote
Stephane Grobety wrote:
> Or are you talking about adding lengthy string/bit manipulation to the
> derivation process just to slow it down so it takes longer to compute a key
> ? It could be a valid approach to defeat on-the-spot, blind brute force
> attack (that is, attack where the attacker doen't know anything about the
> key or the algorithm used to computer it but just tries all possible
> password on a "live" interface).

Something like that.

Quote
>>The point in using CSPs for public key operations is that an attacker
>>may only get limited time oracle access to the keys at worst. The
>>private keys will never leave the CSP, since all PK operations are
>>performed in that box.

> The flaw, of course, is that you need to have some kind of access to that
> box in order to receive the uncyphered stuff. And the only way that the
> hardware can KNOW you have the right to get that information is that if you,
>  somehow, authenticate with it. And in that case, you're back with your
> chicken and egg problem: you need to store that authentication information
> safely.

> Now, if you considere that the machine acessing the CSP is "clean", then
> you don't have the need for that CSP anyway, do you ?

> But the bottom line is, IMNSHO, that you can protect a server, maybe your
> own desktop machine, but you can't could on end-user machine to be fully
> protected: dedicated hardware will not solve that problem.

I think you are missing the point. If you are using software CSPs there
is a chance your private keys will be *permanently* compromised. A rouge
process may retreive them and forward them to anyone over the Internet.
If you are using a hardware CSP your private keys may only be
*temporarily* compromised, for as long as the rouge process is actually
running on your computer.

This doesn't mean that the extra protection a hardware CSP will give you
is perfect, of course, but the difference matters.

Quote
>> From what I've been told you may find such a box for ~$1000.

> Since this is twice the price of the latest, greatest video card around,
> about the same price as a multi-usage printer/scanner/fax/copier or a good
> quality flat screen display, this price is WAY too high to be considered
> consumer product.

Depends. It is not an excessive price considering the value of the
information an individual might potentially have to protect on his computer.

--
Henrick Hellstr?m,
StreamSec http://www.streamsec.com
Borland Technology Partner
Need to security enhance your Delphi application? Don't settle for
anything less than StrSecII:
http://www.streamsec.com/prod_strsec2.asp

 
Stephane Grobet

Delphi Developer
Sat, 19 Feb 2005 23:16:46 GMT

Re:Encrypting a password string.


Quote
Henrick Hellstr?m wrote:
> I think you are missing the point. If you are using software CSPs there
> is a chance your private keys will be permanently compromised. A rouge
> process may retreive them and forward them to anyone over the Internet.
> If you are using a hardware CSP your private keys may only be
> temporarily compromised, for as long as the rouge process is actually
> running on your computer.

How is that ?? The software part needs to get acess to the cleartext stream,
 correct ? To do that, it must persuade the CSP that it is authorized to
use the certificate used to signe the key. In order to do that, some
authentication exchange must take place between the application and the
hardware.

Now, you'll have to store the secret used to unlock the certificate acess
somehow. This means that you will have to fall back in the software only
encryption. And once this has been cracked, a hostile program can use the
keys to it's heart content. Sure, if you move the hardware to a clean box,
you can keep your cripto keys, but the goal is not to be able to reus a
single key no matter what but to trust that this key is a guarantee that
only a valid user/process has can see your information. And in that respect,
 hardware encryption doesn't do you any good.

Quote
> This doesn't mean that the extra protection a hardware CSP will give you
> is perfect, of course, but the difference matters.

I'm afraid the additional protection it offers doen't protect what is
valuable - the data - but what is designed to be changed in case of
compromission - the keys.

Good luck,
Stephane

Henrick Hellstr?

Delphi Developer
Sun, 20 Feb 2005 00:26:22 GMT

Re:Encrypting a password string.


Quote
Stephane Grobety wrote:
> Now, you'll have to store the secret used to unlock the certificate acess
> somehow. This means that you will have to fall back in the software only
> encryption. And once this has been cracked, a hostile program can use the
> keys to it's heart content. Sure, if you move the hardware to a clean box,
> you can keep your cripto keys, but the goal is not to be able to reus a
> single key no matter what but to trust that this key is a guarantee that
> only a valid user/process has can see your information. And in that respect,
>  hardware encryption doesn't do you any good.

Yes it does. You will invest a lot of money in your certificates and you
will be extremely reluctant to purchase new ones just because a rouge
process *might* have had temporary oracle access to your CSP for a
limited time.

If your private keys are protected by software encryption only, you will
*have to* do replace all of your certificates in such a scenario. If
your private keys are stored in a hardware CSP all you have to do is to
clean up the mess caused by the rouge process (e.g. revoke all
certificates it signed with your CA key etc).

--
Henrick Hellstr?m,
StreamSec http://www.streamsec.com
Borland Technology Partner
Need to security enhance your Delphi application? Don't settle for
anything less than StrSecII:
http://www.streamsec.com/prod_strsec2.asp

Stephane Grobet

Delphi Developer
Sun, 20 Feb 2005 15:18:18 GMT

Re:Encrypting a password string.


Quote
> > Now, you'll have to store the secret used to unlock the certificate
acess
> > somehow. This means that you will have to fall back in the software
only
> > encryption. And once this has been cracked, a hostile program can use
the
> > keys to it's heart content. Sure, if you move the hardware to a clean
box,
> > you can keep your cripto keys, but the goal is not to be able to reus a
> > single key no matter what but to trust that this key is a guarantee
that
> > only a valid user/process has can see your information. And in that
respect,
> >  hardware encryption doesn't do you any good.

> Yes it does. You will invest a lot of money in your certificates and you
> will be extremely reluctant to purchase new ones just because a rouge
> process might have had temporary oracle access to your CSP for a
> limited time.

It is only a problem is you're using the "commercially approved"
certificates from Verisign and it's ilk. This might be the only path if
what you want to do is HTTPS to consumer but it doesn't qualify in many,
many business process.

Quote
> If your private keys are protected by software encryption only, you will
> *have to* do replace all of your certificates in such a scenario. If
> your private keys are stored in a hardware CSP all you have to do is to
> clean up the mess caused by the rouge process (e.g. revoke all
> certificates it signed with your CA key etc).

Yes, but you see: if you're talking about commercial encryption, then
you're talking about a very small subsets of all certification system (the
one where you rely one a "trusted" blackm^h^h^h^h^h^hcompany to vouch for
you. If you're using a different asumption (like cases where you don't
trust third parties to hand you a certificate and forget about it), this
gives you very, very little benefit.

And if you're talking about personal encryption (which was the original
subject of this thread, if you remember), it doesn't apply because first of
the cost and apparent uselessness of such system and second because the
keys are really cheap.

Good luck,
Stephane

Stephane Grobet

Delphi Developer
Sun, 20 Feb 2005 21:39:25 GMT

Re:Encrypting a password string.


Quote
Henrick Hellstr?m wrote:
> I think it does. Even if you act as your own root CA normal PKI
> operations will be an expensive investment. Discarding a root
> certificate completely means you have to redistribute the new root
> certificate to everyone in the system and issue new certificates to all
> end users.

In several circumstances, you DON'T want a certificate to be automatiocally
trusted as long as it's signed by a root CA. This is the case where each
application partner has his own certificate and where there simply is NO
valid CA. Think extranet, think commercial partner exchanges: in such cases,
 you don't want to rely on certificate issued by either one of the partner
alone and you don't want to trust a third-party. In such a case, you
exchange certificate that are tied to a single purprose by a secure channel
(i.e. you get it on a CD, hand-to-hand).

Quote
> This is likely to cause a lot of annoyance in the
> organization.

In some case, you don't want any certificate to be accepted but a specific
one. And in these cases, using root certs as the trusting medium is both
akward and dangerous. In fact, in many cases, you'd rather not have a
central cert because it would increase the chances of missuse.

Quote
> If an end entity certificate is suspected to be
> compromised you'll only have to replace that certificate and add the one
> you discarded to the CRL, but that may cause the CRL to grow rapidly out
> of hand; not to mention that the person owning that certificate will
> have to re-encrypt/re-sign all data encrypted/signed by the discarded key.

Sure, but isn't that the whole point ? Beside, many cryptographic document
have a limited validity in time. After a quite short peridoe, they are not
valid any more.

Quote
> Not even exchanging a personal PGP key is without cost, because you have
> to spend a lot of time making people trust it (meeting people in person,
> exchanging keys and have them forward your key through the web of trust).

Compared with the cost of a hardware device, this cost is negligeable. In
practice, people put their public key on public key servers, in their
finger profile or in their Email .sig. Sure, it's not a "good" way to do it,
 but it's the way it's done. And adding crypto hardware wouldn't improve
that anyway because you'd still have to decide which key to trust and which
one not to.
Henrick Hellstr?

Delphi Developer
Sun, 20 Feb 2005 23:16:19 GMT

Re:Encrypting a password string.


Quote
Stephane Grobety wrote:
> Henrick Hellstr?m wrote:

>>I think it does. Even if you act as your own root CA normal PKI
>>operations will be an expensive investment. Discarding a root
>>certificate completely means you have to redistribute the new root
>>certificate to everyone in the system and issue new certificates to all
>>end users.

> In several circumstances, you DON'T want a certificate to be automatiocally
> trusted as long as it's signed by a root CA. This is the case where each
> application partner has his own certificate and where there simply is NO
> valid CA. Think extranet, think commercial partner exchanges: in such cases,
>  you don't want to rely on certificate issued by either one of the partner
> alone and you don't want to trust a third-party. In such a case, you
> exchange certificate that are tied to a single purprose by a secure channel
> (i.e. you get it on a CD, hand-to-hand).

PKI is, more or less per se, not designed to handle such set ups.

The method you describe would be an akward way to exchange keys in such
a scenario. I would recommend exchanging long term symmetric keys
directly through the secure channel and not use any certificates
what-so-ever.

Quote
>>This is likely to cause a lot of annoyance in the
>>organization.

> In some case, you don't want any certificate to be accepted but a specific
> one. And in these cases, using root certs as the trusting medium is both
> akward and dangerous. In fact, in many cases, you'd rather not have a
> central cert because it would increase the chances of missuse.

But that would put you in an even worse situation, because in such case
you would have to redistribute *each* compromised certificate to each
peer in the system, and not just compromised CA certificates.

Quote
>>If an end entity certificate is suspected to be
>>compromised you'll only have to replace that certificate and add the one
>>you discarded to the CRL, but that may cause the CRL to grow rapidly out
>>of hand; not to mention that the person owning that certificate will
>>have to re-encrypt/re-sign all data encrypted/signed by the discarded key.

> Sure, but isn't that the whole point ? Beside, many cryptographic document
> have a limited validity in time. After a quite short peridoe, they are not
> valid any more.

No, that isn't the whole point. The point is that you don't necessarily
have to replace all cryptographic documents if your private key is
stored in a hardware CSP, but that you must if the compromised key is
protected by software only.

Furthermore, while certificates are usually only valid for a limited
time only, signed and time stamped documents may be valid for a great
deal longer. The important question is usually if the certificate was
valid when the document was signed, and not if the certificate is valid
when the document is verified.

Quote
>>Not even exchanging a personal PGP key is without cost, because you have
>>to spend a lot of time making people trust it (meeting people in person,
>>exchanging keys and have them forward your key through the web of trust).

> Compared with the cost of a hardware device, this cost is negligeable. In
> practice, people put their public key on public key servers, in their
> finger profile or in their Email .sig. Sure, it's not a "good" way to do it,
>  but it's the way it's done. And adding crypto hardware wouldn't improve
> that anyway because you'd still have to decide which key to trust and which
> one not to.

Hey, I though we were discussing *secure* PKIs. Why bother about key
compromise if you exchange keys in such a manner. <g>

A real PGP freak will take the key distribution issue a lot more
seriously and gather frequently with other peers just to exchange keys.

--
Henrick Hellstr?m,
StreamSec http://www.streamsec.com
Borland Technology Partner
Need to security enhance your Delphi application? Don't settle for
anything less than StrSecII:
http://www.streamsec.com/prod_strsec2.asp

Johannes Ber

Delphi Developer
Sat, 26 Feb 2005 03:31:11 GMT

Re:Encrypting a password string.


On Fri, 30 Aug 2002 14:04:10 +0200, Henrick Hellstr?m found a keyboard and wrote:

Quote
> Aaargh! I am prohibited by law to export crypto analytical software to
> anyone outside of Sweden. If I weren't, I would seriously consider
> devoting a webpage for easy cracks of all those utility encryption
> schemes for Delphi.

Then set up a website telling people to download "crank" (though its for
linux only I think)
see http://crank.sf.net/

;-)

johannes

Craig Stuntz [TeamB

Delphi Developer
Sat, 26 Feb 2005 03:53:49 GMT

Re:Encrypting a password string.


In article <pan.2002.08.30.15.52.35.428...@sipsolutions.de>, johannes-
n...@sipsolutions.de says...
Quote
> Because having it in some kind of ROT mechanism or whatever is equivalent
> to having it in clear-text, you only *feel* safer, and IMHO that is the
> problem, because people start relying on things like that, when they in
> reality cannot.

        Right.  I didn't want to futz with encryption components for IB
PLANalyzer, so I just store usernames/password in clear text and *tell*
the user (with a warning the first time they select the option) that
this is what I'm doing.  They can either trust that their system is
secure or not use this option.  It's better than using some kind of
psuedo-encryption and making people *think* it's secure.

        -Craig

--
 Craig Stuntz [TeamB] Vertex Systems Corp. Columbus, OH
     Delphi/InterBase Weblog: http://delphi.weblogs.com
     InterBase PLANalyzer (Free IB optimization tool):
          http://delphi.weblogs.com/IBPLANalyzer

Go to page: [1] [2]

Other Threads