4 ms·
You are aware that many popular services allow to share stuff privately using URL encoded credentials?
by mixedbit 13y ago
You are aware that many popular services allow to share stuff privately using URL encoded credentials?
- UnoriginalGuy 13y agoIndeed. Add this to the 1,000,000 other reasons why you should never use GET requests for authentication/verification.
- mixedbit 13y agoWhat do you mean by 'using GET requests for verification'? I think you are mixing different concepts. The problem is caused by URL encoded credentials and has nothing to do with GET requests. It is perfectly fine (and often desirable) to authorize GET requests.
- UnoriginalGuy 13y agoYou can only encode credentials in a URL via GET. Therefore if people stop using GET and start using POST (aka forms) for authentication this issue goes away. Even just a simple pin. GET issues are primarily related to the fact that an attacker can automate their access. So they could trick a user into going to a specially crafted site, and then request content on that user's behalf via GET forgery, and return it to the web-server you control. It is very convenient, but fairly insecure.
- jrochkind1 13y agoyou are also ruling out HTTP auth, yes?
- UnoriginalGuy 13y agoIn the context of this discussion I am.
- StavrosK 13y agoI'm thinking of building a WebRTC-based service to do just that, can you point me to an existing service that does similar things, so I don't waste my time? Thanks!
- UnoriginalGuy 13y agoEverything? Sharepoint, DropBox, Owncloud, LogMeIn, Flickr, Google Docs, et al. Private/one-time-use URLs have been a "thing" since practically forever and they're all over the place.
- StavrosK 13y agoOh, sorry, I misread "private" for "secure". Would anyone here use a WebRTC-based service that also encrypted the file in transit, thus making it pretty hard for anyone other than the recipients to see it?
- drivebyacct2 13y agoHow? The recipients have to manually type in the decoding key? Or they have an account and have been given access internally to the content?
- StavrosK 13y agohttps://myservice.com/#chan=somerandomid&secret=somerandomkey https://myservice.com/#chan=somerandomid&secret=somerand... Then you have to give the URL to the recipient (over a secure channel), but the app will optionally allow you to not automatically send the file, but tell you how many people are connected (e.g. if there are two when you're expecting one) and begin transfer manually. Also, I'm planning to make it all a single HTML file so you can download/verify it and store it somewhere to use whenever you like.
- drivebyacct2 13y agoI wrote a few paragraphs but don't want to talk past you, that sounds fine for a secure channel, but are you going to warn users against using Skype for example? I mean, I don't know if someone has tried Google Docs with Skype, but I know I posted a GDoc link somewhere a while back only to have a bot pop into the doc. So, if the same happens with Skype, someone "joins" this shared resource... and you hit "Transmit"... who or what received it? Of course, Skype's bot won't implement WebRTC. They'll implement the proprietary blend that they told no one they were working on until everyone else was making serious progress with the implementation that everyone else collaborated on... http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web/cu-rtc-web/info http://html5labs.interoperabilitybridges.com/prototypes/cu-r... [hm, they've actually put some money where their proposal is, I'll have to check into this more]