... a company that requires you to twice enter a password with upper case, 
lower case, digits, *and* punctuation, and then mails it to you as a 
confirmation in the clear.  Sheesh.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

On 04/05/2011 05:50 PM, Darren New wrote:
> ... a company that requires you to twice enter a password with upper
> case, lower case, digits, *and* punctuation, and then mails it to you as
> a confirmation in the clear. Sheesh.

How about mailing it to you every 6 weeks in case you forgot it? (Yes, 
I've seen systems that do this.)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 04/05/2011 17:50, Darren New wrote:
> ... a company that requires you to twice enter a password with upper
> case, lower case, digits, *and* punctuation, and then mails it to you as
> a confirmation in the clear. Sheesh.

You know what's worse?

A company that requires you to send files to them electronically using 
SFTP, requires that it uses public key authentication, and emails you 
the private key that you're supposed to use, unencrypted.

People, the entire *point* of public key cryptography is that you should 
never do this! >_<

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> A company that requires you to send files to them electronically using 
> SFTP, requires that it uses public key authentication, and emails you 
> the private key that you're supposed to use, unencrypted.

  I thought the private key can only be used to decrypt, not to encrypt.
(Unless the public key can be created from the private key, which might be
the case.)

-- 
                                                          - Warp

Post a reply to this message

> Invisible<voi### [at] devnull>  wrote:
>> A company that requires you to send files to them electronically using
>> SFTP, requires that it uses public key authentication, and emails you
>> the private key that you're supposed to use, unencrypted.
>
>    I thought the private key can only be used to decrypt, not to encrypt.
> (Unless the public key can be created from the private key, which might be
> the case.)
>

Normaly, you should first create your private decryption key.
Then, from that key, you generate the public encryption key. That key 
can be transmited unencrypted.

Post a reply to this message

Alain <aze### [at] qwertyorg> wrote:

> > Invisible<voi### [at] devnull>  wrote:
> >> A company that requires you to send files to them electronically using
> >> SFTP, requires that it uses public key authentication, and emails you
> >> the private key that you're supposed to use, unencrypted.
> >
> >    I thought the private key can only be used to decrypt, not to encrypt.
> > (Unless the public key can be created from the private key, which might be
> > the case.)
> >

> Normaly, you should first create your private decryption key.
> Then, from that key, you generate the public encryption key. That key 
> can be transmited unencrypted.

  That's not what I was asking.

-- 
                                                          - Warp

Post a reply to this message

On 05/05/2011 05:37 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> A company that requires you to send files to them electronically using
>> SFTP, requires that it uses public key authentication, and emails you
>> the private key that you're supposed to use, unencrypted.
>
>    I thought the private key can only be used to decrypt, not to encrypt.

An asymmetric encryption algorithm has an encryption key and a seperate 
(but related) decryption key. Which one is the "public" key depends on 
which one you make public.

If you make the encryption part public, then people can use it to 
encrypt stuff and send it to you securely. If you make the decryption 
part public, you can use it to sign stuff which other people can verify.

[In some algorithms, either key can be used for encryption, obviously 
with the other key becoming the decryption key. For other algorithms, 
the two keys are not equal and only one can be used for encryption or 
decryption. But that doesn't really alter the point above.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 5/5/2011 9:37, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> A company that requires you to send files to them electronically using
>> SFTP, requires that it uses public key authentication, and emails you
>> the private key that you're supposed to use, unencrypted.
>
>    I thought the private key can only be used to decrypt, not to encrypt.

It depends on the algorithm. RSA can go either way. Otherwise, you wouldn't 
be able to sign and encrypt with the same key.

In either case, sending the "private" key over cleartext and then using it 
for authentication is just as broken as sending your password in cleartext. 
Moreso, because you'd think someone smart enough to use encryption for 
authentication would be smart enough to know that's not how you do it.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message

Le 05/05/2011 20:34, Warp a écrit :
> Alain <aze### [at] qwertyorg> wrote:
>> Le 2011/05/05 12:37, Warp a écrit :
>>> Invisible<voi### [at] devnull>  wrote:
>>>> A company that requires you to send files to them electronically using
>>>> SFTP, requires that it uses public key authentication, and emails you
>>>> the private key that you're supposed to use, unencrypted.
>>>
>>>    I thought the private key can only be used to decrypt, not to encrypt.
>>> (Unless the public key can be created from the private key, which might be
>>> the case.)
>>>
> 
>> Normaly, you should first create your private decryption key.
>> Then, from that key, you generate the public encryption key. That key 
>> can be transmited unencrypted.
> 
>   That's not what I was asking.
> 

Private key and public key are the mirror of each other.
If you crypt with the public key, only the private key can get it back
in clear.
If you crypt with the private key, only the public key ... and so on.

Using the public key to encrypt allows to restrict the number of people
able to read the clear: only the private key can decrypt. It's a kind of
"For these people only".

Using the private key to encrypt is stranger, it would be "From this
people only".


Usually, the private key is used to crypt a checksum of the message
(signing), so that the users of the public key can verify that the
holder of the private key did in fact that operation.

The RWTF is that the private key should not be generated by the company
but by the identified people (you). And they should get your public key,
verify your identity-matching-that-key using a separate *secure*
channel, and then sign your public key with a trust level and their own
dedicated key-pair for that purpose.

The usual private-public key's algorithms allow only to compute the
public key from the private key, at best.
If the private key was computable from the public key alone, it wouldn't
be private any more.

Now, there is also weakness in algorithms, and rainbow book for the some
low length of keys.

For instance DES is weak enough, yet 3DES in some modes (such as Crypt
with key 1, uncrypt with key 2, crypt again with key 3) is assumed
strong enough as long as key2 is not key1 or key3 (moreover, DES use an
internal vector, and some mode propagate/share that vector with the 3
stages, whereas other modes have their own vector for each stage).

And last but not least, usually the asymetric keys (public-private) are
only used to crypt a "random" symetric key (like XOR) generated for the
session (or less), because asymetric cyphering is expensive in CPU
whereas symetric is usually far less.
Which also means that if part of the data exchange can be guessed (such
as a standardised header), the eaves-dropper could try to find the
symetric key in use by comparing the crypted data with the clear one.
(hence the random appeareance of "no-data" packets in the ssh streams:
just to make their lifes more difficult)


-- 
Software is like dirt - it costs time and money to change it and move it
around.

Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

On 06/05/2011 00:38, Darren New wrote:

> In either case, sending the "private" key over cleartext and then using
> it for authentication is just as broken as sending your password in
> cleartext. Moreso, because you'd think someone smart enough to use
> encryption for authentication would be smart enough to know that's not
> how you do it.

If you're using passwords for authentication, it's almost infeasible to 
not make the system extremely fragile. Public key authentication is a 
sophisticated system which solves almost all of these problems... except 
that these people managed to do it so completely wrong as to trivially 
circumvent any extra security provided.

Actually, the key they sent us was password protected. And they sent us 
the password in a separate email. But really, how long is it going to 
take a password cracker to figure out the 8-digit random alphanumeric 
code they used for a password? That's even assuming the two emails 
didn't trickle across the Internet right next to each other in the first 
place.

Still, it's not a major company or anything. *cough* Pfizer *cough*

Post a reply to this message