21–30 of 93 posts
Earlier quoted context omitted.
Yeah it would be a fairly simple fix in code: they could hash some of the user data (e.g. email + name) and then append the id to create a token that won't ever collide and is always unique. e.g. - " rel="nofollow">http://www.flickr.com/invite/?resend= -
Exactly what I was thinking, expiration isn't even necessary.
I'm not really seeing any good reason _not_ to expire them...
Well thats messed up... At least now I know how spammers get my email :D
As jpalomaki points out it's better than that... We are entering a brave new world of spam that's "from" people you know.
Earlier quoted context omitted.
No, we've been there for a long long time now. I use different email address for different people, and virtually every single one of them has been harvested and used to send spam from that person. At this point I don't expect email to be secure at all. You basically have to expect that unless you are dealing with someone with IT skills their email will inevitably get hacked. The implication is that email is NOT a goo…
You don't need to hack someone's account to send mail as them, you just need a server that will get into the popular services. That's the reason social graphs are sensitive, match up people who trust each other and send them messages as each other. Interesting point about password resets though, if you can read (have hacked) the email you're into pretty much any account. BTW in case you're unaware any Android/iOS dev…
They emailed me on an address only used by them in their email, and not in any other service. That only way I could get spam on that address is if their email was hacked. (Either remote, or locally via their desktop.)
I love how publicly posting bugs shifts the balance of power. "schofield" probably though it was just a conversation between Yahoo and the submitter. Now it's a conversation between Yahoo and Hacker News. Welp, the verdict is schofield is being dense. Of course user relationship pairs are potentially sensitive. Therefore enabling attackers to discover them by enumerating your tiny key space is an issue. Either schofi…
"When you speak to a customer, reporter, friend, or any other person not employed by $Company about $Company-related matters, you are acting as a public representative of $Company.
Regardless of whom you speak to or in what context, you must assume your words will be repeated to the entire world as $Company policy.
Your words will be read/heard and interpreted by people of every conceivable level of intelligence and education, in every conceivable cultural context. Even people who have never heard of $Company before and know absolutely nothing about $Company or the matters you are discussing will form opinions based on your words.
People more intelligent, better educated, and more experienced than you in the matters you are speaking about will also read and interpret your words. Then they will speak publicly about them, and further influence others' opinions of $Company.
There are no exceptions."
Earlier quoted context omitted.
Yeah it would be a fairly simple fix in code: they could hash some of the user data (e.g. email + name) and then append the id to create a token that won't ever collide and is always unique. e.g. - " rel="nofollow">http://www.flickr.com/invite/?resend= -
Or just use a UUID.
See http://www.ietf.org/rfc/rfc4122.txt -->
6. Security Considerations -- Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.
So what's missing ? an ID for knowing the first sender, a timestamp, a checking process and a garbage collector to delete the expired ones periodically ? Ok, we don't add a column so easily in the big DB table here, but they can add a sister table with both IDs, the timestamp and a "IsActive" boolean... and start filling the new table with no reference ID, so only the timestamp works for the existed ones. the system will repair itself at the end of the expiration date.
So they can easily afford a giant cluster to throw up phantomjs instances to scape this data in an easily throttleable way. Not that they would be particularly interested in this case, but similar ones for sure.
I think we will see this WAY more in the future. If your email/name retrieval is not an intractable problem, you might as well put up a spreadsheet with the info.
Earlier quoted context omitted.
Or just use a UUID.
UUIDs (depending on the version) could be easier to guess than a hash or random string. See http://www.ietf.org/rfc/rfc4122.txt --> 6. Security Considerations -- Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example.
Furthermore, although the RFC makes a half-hearted attempt to nudge you in that direction, there is no assurance that any of the bits of a UUID are generated in a cryptographically secure manner. If you're using a UUID library that chooses its random numbers poorly, your results may be utterly non-random.