| 1 |
On 11/28/2009 5:03 PM, Dale wrote: |
| 2 |
> chrome://messenger/locale/messengercompose/composeMsgs.properties: |
| 3 |
>> On Saturday 28 November 2009 05:50:42 »Q« wrote: |
| 4 |
>> |
| 5 |
>>> On Sat, 28 Nov 2009 00:57:54 +0200 |
| 6 |
>>> Alan McKinnon<alan.mckinnon@×××××.com> wrote: |
| 7 |
>>> |
| 8 |
>>> [about LastPass] |
| 9 |
>>> |
| 10 |
>>> |
| 11 |
>>>> What I find incredible is that people will accept the site's say-so |
| 12 |
>>>> that the site admins can't read the data. They have not proven |
| 13 |
>>>> anything, merely asserted something. |
| 14 |
>>>> |
| 15 |
>>>> The only way to do give that guarantee is to encrypt the data. Which |
| 16 |
>>>> then needs a key. Someone must keep the key and it's either you or |
| 17 |
>>>> them. If it's them, they can decrypt the data (same reason as DRM is |
| 18 |
>>>> doomed to failure) and if it's you - well if you lose the key you |
| 19 |
>>>> lose the data. |
| 20 |
>>>> |
| 21 |
>>>> Are you telling me that there are people gullible enough to actaully |
| 22 |
>>>> fall for that one? |
| 23 |
>>>> |
| 24 |
>>> They claim that the decrypted data never leaves your computer and they |
| 25 |
>>> they don't have a key to it. Many, many things aren't clear, such as |
| 26 |
>>> what kind of encryption is used (same as the US gov't uses for "Top |
| 27 |
>>> Secret" stuff, they say, heh), where and how the key is stored on your |
| 28 |
>>> machine, on and on. I wouldn't dream of using them, but yeah, they have |
| 29 |
>>> a substantial number of users. |
| 30 |
>>> |
| 31 |
>> I have an alarm system in my head. It's called the "Security by bullshit |
| 32 |
>> baffles brains Alert". It's ringing right now ;-) |
| 33 |
>> |
| 34 |
>> Mind you, I have vendors who use exactly the same throw-around-bullshit- |
| 35 |
>> statements-and-see-what-sticks approach. It works on the Account |
| 36 |
>> Managers all |
| 37 |
>> the time, and works on us techies none of them time. |
| 38 |
>> |
| 39 |
>> Lucky for us, techies rule around here. We get to tell the Account |
| 40 |
>> Managers |
| 41 |
>> that the vendor is talking crap, that we don't have to explain why, |
| 42 |
>> that we |
| 43 |
>> are not buying their crap and we are not using it, so please tell the |
| 44 |
>> vendor |
| 45 |
>> to leave the building and stop wasting my time :-) |
| 46 |
>> |
| 47 |
>> |
| 48 |
> |
| 49 |
> And to think I came here to ask others opinion BEFORE doing this. I |
| 50 |
> was curious as to how this could work myself and if they can be |
| 51 |
> trusted, or SHOULD be trusted. Seems everyone thinks no one should. |
| 52 |
> |
| 53 |
> That said, because of the way my bank and credit card site accepts the |
| 54 |
> login and password, I bet it wouldn't work for them anyway. If I |
| 55 |
> wanted a really long password that would be hard to guess, those two |
| 56 |
> would be it. |
| 57 |
> |
| 58 |
> Dale |
| 59 |
> |
| 60 |
> :-) :-) |
| 61 |
> |
| 62 |
For my two cents, I would not trust anyone with my passwords, encrypted |
| 63 |
or otherwise. Anyone who falls for this kind of thing should go learn |
| 64 |
about security being a mindset, not a software package, and then check |
| 65 |
out wikipedia's page on email viruses and the like. |
| 66 |
|
| 67 |
Marcus |
Archives