161–170 of 385 posts
A post-it note that says “my daughter’s birthday” written on it is secure in the same context. Even if it upload a picture of said post-it note to Dropbox.
https://1password.community/discussion/63045/moving-beyond-1...
If stores all the passwords in encrypted js files, which the 1password.html would read in and allow for totally offline password access.
This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure). Passwords: - Easy to memorize. Pro: Does not rely on a device, can be recovered if devices stolen. - Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret. - Easy to brute force. Con: Rel…
Thank you for the comment and thoughts. Agree with most, disagree with some (easy to brute-force?), but I wanted to comment on this in particular: > Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret This to me is the most glaring "vulnerability". i.e. I use this to exchange letters with my friend Bob. Now someone impersonates…
This is an ingenious idea, one that becomes obvious only in retrospect. To me this feels like a merger of the ideas in projects like magic-wormhole, Wormhole.app, and the (defunct) Mozilla Send. But then it adds a kind of sharchive twist using the browser as a runtime. The original paper I saw called it Password Authenticated Key Exchange. https://www.cs.columbia.edu/~smb/papers/neke.pdf But I think the general form…
Earlier quoted context omitted.
Even if not, it's affordable to hire a programmer for a few hours to migrate the code to the newer API.
I doubt that would work. You can’t decrypt things encrypted 20 years ago on modern API’s because those algorithms are known to be insecure. You’d have to probably rewrite it from scratch or install an old version of the browser. So it’s probably best to keep a windows version of the browser since that’s currently the only OS that can run software from 20 years ago, so hopefully they’ll still be able to do that 20 yea…
Consider a magic unpickable door lock that automatically unlocks itself at midnight. The lock has no security vulnerabilities (it's doing exactly what it's supposed to, and there's no way to subvert it), but your house probably does.
I don't understand. Sure you sent these over an insecure channel and they end up... Being opened from a website, in a browser which downloaded JavaScript (JavaScript which may or may not be the same you downloaded yesterday when you used that same site btw)?
And we all know that browsers running unverifiable JavaScript from some Website are a... secure endpoint?
It's not a criticism: I'm probably missing something (is this something I'm supposed to run on my own server or on some computer I take offline after having opened the website from a harddisk-less system booted using a Linux Live CD?)?
How is this not something where you need to trust the website/server?
For all I know upon entering the password the secret is sent to the server over the wire.
Sure, fine, let's disconnect the computer from the Internet before entering the password...
Well then for all I know the JavaScript just downloaded may be saving the data or the secret in a cookie or whatever that is going to be read the next time the site is going to be accessed (so even opening it offline ain't sufficient: it must be done from a system which cannot persist to disk right?).
P.S: as an addition "Do you think this cannot possibly be secure? Great, prove it. This secret contains the recovery key for a Bitcoin wallet. Crack it and take my money!". I'm sorry but that's not how security works. It simply ain't. Once again: I'm probably missing something but reading this thread so far I feel I've been catapulted in an alternate reality, complete with people thinking that this message is somehow a proof that this scheme is secure (which it may or may not be, but that people cannot steal the coins ain't proving jack shit).
> Crack me if you can This reminds me of LifeLock CEO's Todd Davis public challenge [1] when he revealed his Social Security number prominently on his site and billboards with overconfidence that his identity cannot be stolen but, unfortunately, he's been a victim of identity theft at least 13 times. 1. https://www.wired.com/2010/05/lifelock-identity-theft/
I'm not that confident in my tool. That said, I ask myself every day if having my public identity associated to my project, website, etc. Was a good idea. It certainly helped with jobs in the past, but it's scary to hear stories of devs impersonated by others.
This has some desirable security properties, but I would like to see more analysis on the security side (not just: is secure or is not secure). Passwords: - Easy to memorize. Pro: Does not rely on a device, can be recovered if devices stolen. - Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret. - Easy to brute force. Con: Rel…
Thank you for the comment and thoughts. Agree with most, disagree with some (easy to brute-force?), but I wanted to comment on this in particular: > Easy to phish. Con: Attacker can use a look-a-like page, click-jacking, and pixel extraction (frame stealing) attacks to get password & secret This to me is the most glaring "vulnerability". i.e. I use this to exchange letters with my friend Bob. Now someone impersonates…
"Relies on human adherence to password best practices to maintain sufficient entropy. Learning from industry that this does not work in widespread adoption"
The GP's statement can be boiled down to: "users will choose poor passwords" (as in Password1!) because it has been shown time and again that "users will choose poor passwords" if left to their own devices to do so.
The 'easy to brute force' part then comes in as "for those users who choose poor passwords, this rig linked below will brute force their passwords pretty quickly":
https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
Note that the above performance page is a few years old, updating it for 8x of a newer Nvidia GPU should result in even more impressive performance numbers.
And in all fairness, any cryptography where a user chooses a poor password is then vulnerable to "easy to brute force" by a rig such as the one above. Not because the encryption algorithm is easy to brute force (usually it is not) but because the user picked a poor password, and that poor password itself is easy to brute force.
No complex, million+ SLOC codebases to install, except the one browser. I'll stick with gpg signing my pass repo and call it a day.