| 1 |
On Tuesday, 5 February 2019 07:55:41 GMT Dale wrote: |
| 2 |
> Mick wrote: |
| 3 |
|
| 4 |
> > https://en.wikipedia.org/wiki/LastPass#Security_issues |
| 5 |
> > |
| 6 |
|
| 7 |
> From what I read, no users had their passwords compromised in those. |
| 8 |
|
| 9 |
I read it differently. LastPass didn't know if any passwds were compromised |
| 10 |
(or wouldn't tell you). As a precaution they asked users to change their |
| 11 |
master passwd, while they changed their server's salt. In addition, there |
| 12 |
were XSS vulnerabilities later on, which is probably to be expected with |
| 13 |
JavaScript and similar technologies. |
| 14 |
|
| 15 |
|
| 16 |
> As |
| 17 |
> I pointed out earlier, the passwords are already encrypted when they are |
| 18 |
> sent to LastPass. If I called LastPass, could prove I am who I claim to |
| 19 |
> be and asked them for a password to a site, they couldn't give it to me |
| 20 |
> because it is encrypted when it leaves my machine. |
| 21 |
|
| 22 |
I don't know exactly how the LastPass architecture is configured, other than |
| 23 |
it relies on device based encryption activated with JavaScript, but anomalies |
| 24 |
they observed in incoming and outgoing traffic on the 2011 incident indicate |
| 25 |
someone was interfering with their data streams. Given Diffie-Hellman could |
| 26 |
be compromised (e.g. as per Logjam) by precomputing some of the most commonly |
| 27 |
used primes in factoring large integers, it may be someone was undertaking |
| 28 |
comparative analysis to deduce ciphers and what not. If the server salt was |
| 29 |
obtained, then one layer of encryption was compromised. |
| 30 |
|
| 31 |
All this is juxtaposition and my hypothesizing does not mean LastPass is not |
| 32 |
useful, or not secure. It just means its design is not as secure as locally |
| 33 |
run simpler encryption mechanisms, which do not leave your PC and are not |
| 34 |
stored somewhere else. |
| 35 |
|
| 36 |
The greater surface area a security system exposes, the higher likelihood |
| 37 |
someone will take a punt at cracking it. A browser, sandboxed or not, has far |
| 38 |
too many moving parts and exposed flanks to keep crackers and state actors |
| 39 |
busy. I expect with advances in AI this effort will accelerate |
| 40 |
logarithmically. |
| 41 |
|
| 42 |
|
| 43 |
> As I pointed out to Rich, I don't expect these tools to be 100%. There |
| 44 |
> is no perfect password tool or a perfect way to manage them either. No |
| 45 |
> matter what you do, someone can come along and poke a hole in it. If |
| 46 |
> you use a tool, the tool is hackable. If you use the same password that |
| 47 |
> is 40 characters long for several dozen sites, then the site can be |
| 48 |
> hacked and they have the password for those other sites as well. The |
| 49 |
> list could go on for ages but it doesn't really change anything. We do |
| 50 |
> the best we can and then hope it is enough. Using tools is in my |
| 51 |
> opinion better than not using a tool at all. At the least, they will |
| 52 |
> have a hard time breaking into a site directly without my password. It |
| 53 |
> beats the alternative which is cutting off the computer and unplugging |
| 54 |
> it. :-( |
| 55 |
|
| 56 |
Yes, well said. A disconnected and switched off PC is probably quite secure, |
| 57 |
but what use is this to anybody. LOL! The effectiveness of PC security is |
| 58 |
challenged on a daily basis and you eventually have to arrive at a personal |
| 59 |
trade-off between security and usability. |
| 60 |
|
| 61 |
-- |
| 62 |
Regards, |
| 63 |
Mick |
Archives