HN user

abentspoon

386 karma

micah@qwerjk.com

Posts4
Comments47
View on HN

is having me click on an email going to make it more secure?

We implemented this at Mercury recently to stop phishing attacks, and I believe Coinbase implemented it for the same reason [1].

TOTP authenticators are super ineffective at combating phishing. If a user is willing to give their email and password to a phishing site, there's very little standing in the way of them also providing their TOTP code.

WebAuthn solves this by working with the browser to tie authentication to a particular domain, but not everyone has a WebAuthn authenticator yet.

Meanwhile, email verification links are a really simple and effective way to shut down these phishing attacks. The phisher can't click the links, because they don't have access to the user's email. The user can't click the links on behalf of the phisher, because clicking the link only verifies the device that clicks the link.

1. https://www.reddit.com/r/Bitcoin/comments/2rp9o4/beware_coin...

Update: On a more detailed examination of those two states, I’m convinced the contrast here is due to differences in the sizes of the blocks. North Dakota’s blocks are more consistently small (StDev of 3.3) while South Dakota’s are more varied (StDev of 9.28). West of the Missouri River, South Dakota’s blocks are substantially larger than those in ND, so a single inhabitant can appear to take up more spaaaaaace. Between the states, this provides a good lesson in how changing the size and shape of a geographic unit can alter perceptions of the landscape.

First, it looks like this scheme is broken due to cpu constraints. However...

It had looked more like the encrypted bloom filter was intended to prevent the client from obtaining the list of registered users.

With (1) + (2), the server only has a few bits of information about each of the phone's contacts. It would be analogous to just having the area codes.

Good point. Now I understand why they were suggesting bucketing.

I came up with this method for maintaining privacy while retrieving installed apps (to give app recommendations). Sounds like it might not translate across so well.

What about this?

1) Client uploads a bloom filter with all contacts on phone

2) Server responds with a bloom filter with all registered contacts that match the client's bloom filter

3) Client displays contacts that match server's bloom filter

You can optionally trade contacts back and forth again with a larger bits/contact ratio to decrease false positives.

I think it works out so that in exchange for 7 bits of information about each contact from the client, you can reduce the server's response by a factor of 128.

33 Questions 13 years ago

It's not enough to find 33 independent questions that evenly split the world's population.

An optimal, though inelegant solution to that goal might look something like this:

"Is the {1..33}th bit of sha1(name : location : date of birth) 1?".

Clearly you'll have tons of collisions with that solution, as you would have with any solution using 33 independent questions.

To uniquely identify people, we'd either need to use more bits, or look very closely at the population and derive very specific questions.

Interesting. I was going to complain, as I thought "probably" meant the probability of occurrence was greater than 50%.. That doesn't seem to be the case.

  Probably: almost certainly; as far as one knows or can tell
I would guess waynecochran thought something similar.

I don't know if intrinsic value is the right term, but I've been thinking along the same line.

A Bitcoin is essentially a tradable hashcash, which has direct value in spam filtering.

"Isn't it enough that I ruined a pony, making a gift for you?

It's not just about confidence.

If the price is being driven by new speculative investment (ie, a bubble), the price should stagnate as fewer speculators join the pool. If the price stagnates, there will be little incentive for purely speculative investors to keep their money in BTC.

The last cynic buying in is just an indicator of late-adopters hitting the market, signaling little gains left to be had.

Thanks to $elemMatch and automatic parameter parsing, this vulnerability is easier to exploit than it would seem.

In rails, both of these are usually considered safe:

    MysqlCollection.create(:name => params[:name])
    MysqlCollection.where(:name => params[:name]).all

    MongoCollection.create(:name => params[:name])
    MongoCollection.where(:name => params[:name]).all
However, the mongo version is vulnerable to this exploit.
    /create?name[0][whatever]=anything
    /get?name[$elemMatch][$where]=exploitcode

Better still, increment hotness by 2^(dt/λ) where dt is the time since the site was launched (epoch), and λ the halflife of an upvote. No worker process needed.

Doubles will go to infinity after a few years, but you can either reset the epoch at that time, or store the significand and the exponent seperately.