Live data from Hacker News

Flickr: Invitations disclosure (resend feature)

hackerone.com

51–60 of 93 posts

Re: Flickr: Invitations disclosure (resend feature)

#51
post #4

The collision rate seems pretty high and to someone with a bit of resources (say 500 ips) to go through the ids would take 3~ days at 1 request per second. The party would have a list of of flickr users / email combinations. The best way to fix this if they want to have the urls work for some backward compatible reason is probably severe rate limiting after x requests if they do not want to expire these requests -- r…

[deleted]

Re: Flickr: Invitations disclosure (resend feature)

#52
post #46

Actually the Yahoo! employee (schofield?) in the above link is right and you cannot blame him for this - it is because Yahoo! really think first name + last name + email are not private information AFAIK, not particularly to Flickr, there are multiple ways to retrieve these information...

Relations are another interesting thing. That would make phishing much more effective. Though I suppose somebody's Yahoo profile page should get them access to that as well.

Re: Flickr: Invitations disclosure (resend feature)

#54
post #46

Actually the Yahoo! employee (schofield?) in the above link is right and you cannot blame him for this - it is because Yahoo! really think first name + last name + email are not private information AFAIK, not particularly to Flickr, there are multiple ways to retrieve these information...

I work on both sides of the fence. I respond to reports by researchers and I submit my own fair share to a large number of companies. The problem that is always present and which all employee's taking vulnerability reports need to understand is that there are scenarios outside of their realm of thinking which could bite them. In this case Schofield shouldn't have pushed back on the researcher and instead used the report as justification via a 'headline test' with the development team to make what should have been a simple code modification to use a strong random identifier. Instead Schofield introduced organizational bias that the information wasn't sensitive and now looks rather silly as a result, especially given it looks like the issue may have just been remediated. It is never good when a problem can't be tackled within a 30 day window at the frustration of a security researcher but can then be tackled within a matter of hours over a weekend.

Re: Flickr: Invitations disclosure (resend feature)

#55
post #9

The response to this bug is atrocious and shameful. The developer that responded to this did the same as putting on a blindfold and declaring that because they could no longer see the bug, it must not exist. Right from the get-go, schofield showed incompetence when they declared they couldn't reproduce the bug, even though it was explained to them plainly and thoroughly! How do these inept developers get hired?

Furthermore, Yahoo can not unilaterally choose to define what is "sensitive". In the EU, many countries implementation of the Data Protection Directive considers e-mail addresses personally identifiable information, which makes it subject to the relevant laws. Given that Yahoo operates in a number of European countries, and have offices and legal entities in many of them, this potentially means they are legally liabl…

Indeed. In Spain, the LOPD (Data Protection Law) states that the email is personal information. Many companies have been fined for leaking emails, specially when sending mass emails with all the addresses in the "To:" field instead of BCC.

Re: Flickr: Invitations disclosure (resend feature)

#56
post #40
post #4

The collision rate seems pretty high and to someone with a bit of resources (say 500 ips) to go through the ids would take 3~ days at 1 request per second. The party would have a list of of flickr users / email combinations. The best way to fix this if they want to have the urls work for some backward compatible reason is probably severe rate limiting after x requests if they do not want to expire these requests -- r…

This is not a collision rate. Collision is when two plain text gives the same hash.

col·li·sion kəˈliZHən/Submit noun 1. an instance of one moving object or person striking violently against another. "a midair collision between two aircraft" synonyms: crash, accident, impact, smash, bump, hit, fender bender, wreck, pileup More an instance of conflict between opposing ideas, interests, or factions. "a collision between experience and theory" synonyms: conflict, clash; More 2. COMPUTING an event of two or more records being assigned the same identifier or location in memory.

Re: Flickr: Invitations disclosure (resend feature)

#58
post #26

Earlier quoted context omitted.

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.

Under no circumstances are RFC-compliant UUIDs of any version as secure as a properly-generated 128-bit (or more) key. Even version 4 and 5 UUIDs necessarily have non-random bits. 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…

Even so, UUID's would be nearly infinitely better than the current model of incrementing integers! Wow...

Re: Flickr: Invitations disclosure (resend feature)

#59

The response to this bug is atrocious and shameful. The developer that responded to this did the same as putting on a blindfold and declaring that because they could no longer see the bug, it must not exist. Right from the get-go, schofield showed incompetence when they declared they couldn't reproduce the bug, even though it was explained to them plainly and thoroughly! How do these inept developers get hired?

Why do you think schofield is a developer? I didn't see any indication in this conversation.

Every company I have worked for has a support organization that deals with customer tickets like this. They might escalate the issue to development, or they might not. But either way they're the ones involved in the conversation.

Re: Flickr: Invitations disclosure (resend feature)

#60
post #46

Actually the Yahoo! employee (schofield?) in the above link is right and you cannot blame him for this - it is because Yahoo! really think first name + last name + email are not private information AFAIK, not particularly to Flickr, there are multiple ways to retrieve these information...

I wonder what it would take to compile a directory of companies and the way each one classifies each piece of their users' data.

For example, at the company I work for, we have a master list, with several levels. Things like password and SSN are the most sensitive, and have much more stringent requirements for how we handle them than a user name.

I think it'd be useful as a user to know what each company's policies are. Ex: Yahoo doesn't mind linking name/email publicly, so maybe I give them a false name. It'd also be useful for companies to compare themselves to their peers, and make corrections if/where they diverge.

Post reply on HN