Comment by mprime1 | Hacker News Reader

Comment by mprime1 | Hacker News Reader

Parent Full thread

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 me and sends a fake 'PortableSecret' to Bob that siphons out the actual password.

Clearly this is a valid vector of attack, and one I made no attempts at defending from.

The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous.

I have to keep reminding myself this is a real vector, but the fear is irrational.

As they say at DEFCON to people too concerned using their devices: "Nobody is wasting their 0day on you".

I don't think I'm a target valuable enough to attract this kind of attacker.

I agree that each person/organization should look at the security properties of a system and assess their risk against what technology is appropriate. It's entirely reasonable that as a non-targeted person with low value secrets, many of the attacks here don't have ROI for a potential attacker and as a result are neither likely or impactful.

What's important is that other persons and organizations who may be targeted - that they choose what technology to use, knowing what kinds of attacks are possible. For example a human rights activist might very well be targeted by phishing attacks and choose not to store secrets by this method.

I am just trying to enumerate the properties so that persons/organizations can evaluate a match to their use case. I don't believe any system is perfect for all use cases and I don't hold any system to such a standard.

The GP comment about "easy to brute force" must be read in context with the remainder of the comment about "easy to brute force":

"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.

Right, agree with all of that. I would have characterized as "user can shoot themselves on the foot (i.e. by choosing weak password)", rather than "easy to bruteforce"

It's a perspective difference.

Each individual user perspective: "It is possible I can shoot myself in the foot, and also possible I will not. It is not correct to say I will shoot myself in the foot.".

Outside observer perspective: "Empirically, many users shoot themselves in the foot using this system. It is correct to say this system does not make feet safe".

It might be phrased better in terms of safety than security? The safety of the system is left up to the users, and is - to the best of our knowledge - not safe to use _as is_ by most people.

But users choosing a weak password on a standard rate limited service login is significantly different to choosing a poor password in something that the attacker has unlimited, low latency and undetectable attempts against.

I agree with the point about unlimited and undetectable. I think there's nuance to low latency.

Here the latency the attacker is limited by the amount of parallelism they can bring to bear on e.g. PBKDF. Ultimately this is an economic consideration about the cost to protect a secret vs cost to crack it.

> The thing is... this won't happen. If I'm dealing with an attacker so sophisticated to pull this off, it's likely they have 1000 other vectors that are more effective and dangerous.

Don’t delude yourself. These phishing pages with mirrored login portals happen to podunk organizations all of the time.

If someone manages to get a link to your page and is interesting in the contents, duping it and sending a phishing link to the suspected password holder is a trivial spear phishing attack (with an annoyingly high success rate).

mprime1 feel free to use or alter any of the content you agree with to update the documentation for your project.

Reply on news.ycombinator.com