The games on Stripe's CTF were more secure than this site...
EDIT: Looks like it was just patched. Still managed to get a few dozen AWS keys though.
"Looks like it was just patched. Still managed to get a few dozen AWS keys though. I sent emails to the affected parties."
EDIT: effected-> affected (I'm not sure what's up with the snarky comment. Do most people think its inappropriate/snarky to urge proper notification?)
The concern isn't just that RKearney has the keys - it is that anyone could have the keys for anyone on the site. Sending an email to the people whose keys he snagged would help them - but the people whose keys he didn't are still vulnerable too.
Do I think the developer should email all of the users? Yes, which is why in my response to the developer's comment about destroying the IAM keys I said "You should think about sending an email to all of your users..."
Do I think that the right thing for rkearney to do is send emails to the people whose information he has? Yes. Is it the best possible scenario? No, but it is better than no notification at all, which at the time was a possibility.
if anyone's concerned about your AWS key, just destroy your IAM user and create a new one. that's what it was designed for.
actually, we'll just wipe them and force new ones.
We each have 24 hours in a day. I spend 8-9 of mine sleeping, 9-10 at work. That doesn't leave much leftover for me.
If zacharyvoase wants to spend his precious free time educating people who haven't done any due diligence to learn how to build a secure web app, that's his prerogative. But I don't see it as a good use of his time - there's already tons of resources out there that will do a better job than zachary. Is HN supposed to be a newbie education destination?
Congratulations on demonstrating to me and countless others why I shouldn't use any product that you EVER touch. You don't get a pass because you're just two nerds. You have a form with a submit button -- that's where your responsibility as a founder and custodianship of user data begins. Day 1, you're already a liability.
I realize this is a pretty direct attack but I'm appalled and staggered by your behavior in this thread. You launched a service on the public Internet. There is no grace period, there is no "friendly fire"; you fucked up and you disclosed AWS credentials. Not users' favorite colors. AWS KEYS. Tied to credit cards, running servers, S3 backups, God knows what. You don't get to tell people to be nice to you when you're acting as the steward of AWS credentials; you protect them and act like you care when someone tells you that you fucked up doing so.
Your behavior here is just foreboding for the future, and you need to realize that before launching your next endeavor (this one is probably done, after that little mess).
You are quickly making the case for having one of the worst responses I've ever seen, to a huge security flaw. Trying to wipe things under the rug when your users information is clearly exposed is an easy way to destroy trust.
I seriously can't fathom the ineptitude it takes to direct people to someones email like that over your glaring mistake.
RKearny pointed out a very real, very important issue that will help you make your service better, and help you deliver even more value for your users. And he did it for free! You should be thanking him and asking him for more feedback, not deflecting responsibility like this.
i'm not sure why thanking him is in order... ?
5 people emailed me privately about the security issue. we fixed it promptly, and followed up with instructions to everyone exposed (~20) on how to protect their credentials. i haven't yet heard a complaint from our actual users.
I can search for email addresses too! Don't direct users to me because you failed to secure your web application.
It's nice to know someone who works at a company that handles credit card and bank payments would just post someones email address and photo. Granted this is all public since I posted on the Uservoice post, it was still unnecessary.
i left WePay ages ago. also, our info is publicly displayed here:
we're not a company. we're two nerds.
Oh, so if you get sued for mishandling personal data or PII it'll be your personal responsibility rather than a company's?
"Still managed to get a few dozen AWS keys though"
Good for you! What a nice person you are. Please abuse more small projects like this. Even if they say they say it was "was only meant for friends to test out".
Oh I see, you just found a security hole and trying to get some reputation? Cute. Please do it by abusing the small power you found and hurting innocent users. That's really, really nice of you.
Wow. Just wow.
You sir, just ruined my night. Thank you.
Ps. I am really concerned about your company and its users. If you can do something like this, I wonder what else you could do (or doing) at your current company. I hope, I'm assuming wrong.
edit: "the" » "your". last paragraph.
1. I didn't disclose how to do it, merely that it was possible.
2. By "get" I in no way mean harvested. I just manually incremented the ID in the URL by hand in my web browser to see how many users could be affected.
3. Since I never saved any of the information (just viewed the pages) I no longer have it since the flaw was patched.
Nothing malicious was done.
I'll update my comment above.
As it stands we don't know whether hostile agents (silently) got copies of the AWS keys of every user on the site. That should be incredibly concerning for you, but apparently it's not.
I'm still trying to improve my English. Next time I'll try to be more clear. Thank you.
The problem with this is that people become more skeptical in general about new products/companies, which is bad for the community as a whole.
The issue here is how do you deal with this kind of thing? Assuming it is in fact bad for others who are trying to get people to test their prototypes, how do we help avoid basic pitfalls like this one? This could be a service...
You can find a security hole and report it. That's nice and good behavior. But when you say "I have compromised the data with me", then you are being evil.
I signed up to the app because I liked the idea and wanted to support them. I knew that their app was in alpha stage yet.
I'm upset about his behavior.
I'm upset that his behavior might hurt 2 nerds' inspiration.
I'm not upset about he got my keys.
But you are right. His behavior is still better than not saying anything.
I'm hoping they're inspired to write secure code from line one.
How much? $7.20 per gigabyte for your highest hour (minus a negligible free allowance if you're using it in this manner).
i.e. the cost to restore m gigabytes over n hours is:
$7.20 * m / n
I'm sure Ice Box Pro will have warnings in place, so nobody will get a $350 bill by accident by restoring a 50 gig account in an hour.
But for disaster recovery, the time will come to decide between a large bill or a very slow retrieval.
Pricing details are here (though quite difficult to follow):
I wonder why they don't use S3. Is it not reliable enough? The charging infrastructure at least is simpler to figure out.
For example, in several states, all records relating to a minor in state custody, an adoption, or receiving certain nbenefits must be kept for 26 years after the minor turns 18. Today, states are either storing this data on tape, or paying some government contractor to do it for them -- at an expense several times that of Glacier.
Another example is litigation holds. One former employer was forced to hold around a petabyte of data 7 years for a complex civil suit, because... A judge said so. In that case, the high cost of retrieval may be a benefit, because the plaintiff would be footing the bill.
You're right that an upfront retrieval speed vs cost interface is the correct way to handle it, preferably on first use.
I'd prefer the speed/cost interface to be at download time. Give the opportunity to reorder the download sequence to prioritise some parts and probably transfer to S3 so the local computer doesn't need to be running throughout the whole data trickle.
That's a useful service that I can't be bothered to build at the moment.
EDIT: Removed comment about competition.
i built this with a friend and didn't expect it to get posted to HN already. we just got it approved and i accidentally hit our Like button before we were even ready. my friends immediately commented on the story so we just said, what the hey :-)
in any case, it just "launched" today, was only meant for friends to test out, and yes i agree we need to write more copy.
to address some concerns:
- this is really only meant for developers at the moment; i.e. those who actually know their way around AWS. if and when we decide to take payments and provide a service, you can expect a lot more documentation and support. we have no desire to dupe normal folks. we built this for ourselves and really only expected friends to try it out first.
- you don't need to go to your AWS console to get your files. once a file archives, you can click a button to download it back to your Dropbox
- putting in warnings about the quota is a great idea! we'll do that ASAP.
keep the feedback coming, we really appreciate it and wanna build something useful for everyone.
most likely, we'll just keep a small data center. something to get around the bandwidth limitation and availability. we would definitely need to charge then in order to cover those costs.
I only have 2GB of Dropbox space because I never upgraded. But I have about 100GB of archive data I'd probably throw into Amazon Glacier if it were convenient.
Do I need to open a 100GB Dropbox account before using IceBox?
What I'm thinking is a service that uses Glacier to store my photo library and some type of front end service (like dropbox) that keeps a low res version of that photo along with some meta data about it.
My reasoning for this is that we all build up pretty significant photo libraries (mines already over 60GB) and I'm always trying to make sure I have them backed up. I currently use a paid plan at Dropbox so I can put them all up there but it's kind of a waste since I hardly ever pull many of them down again. Every once in awhile I browse through them looking for certain pictures that I might need to get a copy of (which is why I'd need the low res copies easy to access/browse) and then be able to choose which ones to pull down from glacier. The other good thing about a service like that is the need is not typically immediate.
Maybe I'll look into building this since it's something I'd love to have for myself!
We came to the conclusion that putting files on BluRay disks or hard drives and keeping them physically separate was the best solution for the cost. The problem is that disks take a long time to burn, and external hard drives aren't the best archival medium (not to mention they don't always travel well).
Has anyone here solved the problem of data backups where bandwidth limits make pure online/cloud storage infeasible?
Hosted version: https://openphoto.me
Project page: http://theopenphotoproject.org
Ideally, we would be able to ship BluRays to a data center (USPS has terrible latency, but great bandwidth!), where they would load them into their servers. If anything happend to the local copies, we could either have them ship us back a hard drive or BluRays, or download the lost files (downstream is much faster for us, and because we are theoretically only downloading a subset of what we backed up, direct downloads are feasible).
The issue I run in to in my thought experiments is that a data center doesn't necessarily want to physically handle data shipped to them or create recovery media to ship back.
Actually, all that is really needed is a secure place to archive the BluRays. A way to view and download backed up files is a nice-to-have, but not required.
Probably not cost effective for them but that's what you're looking for, I think.
Amazon will accept delivery of hard disks and load the stored media in to S3/Glacier:
The OpenPhoto Project is what you're looking for. Open source, installable and offered as a hosted service.
I let it handle other drives, too, although I exclude my media/music/download/etc drive for simplicity.
Rather, it's an optional yes.
EDIT: Actually, it looks like they can decrypt your data to restore it on their end, so it's a no.
Of course, if you have so sensitive stuff that you cannot accept it ever being on another server in clear text then it still a no on that question.
akmiller, can we talk offline? i'd love to hear more about your ideas. (we actually have photos in mind.)
just email firstname.lastname@example.org
There's a great app called Arc that handles all of Mac OS X meta data perfectly, works with the relative ease of Dropbox, and backs up to S3 at great savings. De-duplication and other "smarts" are all there.
It's sort of like a Time Machine that you can point to S3.
Try it out if you want, 1GB accounts are free at the moment:
It doesn't show any pricing. I don't want to sign up for something just to see the pricing.
The landing page not being finished was why I'd been waiting to launch, wish I'd got it done sooner now!
EDIT: Until I sort out the landing page here's the current pricing: 50GB is $25/year, 100GB is $40/year and 500GB is $189
The benefit I see is that customers would have total visibility into their own data, and, of course, it's very cheap to run a system like that.
I'd love to hear any opinions anybody might have about it.
This tool is great for me because the data I'm backing up is something I'll need to access maybe twice a year, or less. But I still need to have this data backed up somewhere.
I love how it's as simple as Dropbox. Set it up once, the rest is just drag and drop.
Does Amazon provide a fairly decent interface? Or, failing that, are there clients that can work with AWS Glacier already, the way some FTP clients can speak to AWS S3?
Good luck with icebox.
From the Dropbox brading guide ( https://www.dropbox.com/developers/reference/branding ):
> you can use the Dropbox logo in marketing material to show your app's Dropbox integration, but it should never be modified and should always refer to our service. If you are using the logo on a website, it should link to https://www.dropbox.com.
So they're allowed to use it, but it must link to the Dropbox website. It doesn't so it's actually violating the guidelines.
we have no intentions of competing with Dropbox. (like that's even possible.) if we get a complaint, we're more than happy to comply.
we love both Dropbox and Amazon Glacier so we decided to pair them. i'm almost certain Dropbox will eventually add a similar feature soon--we may just be beating them to the punch.