@bentossell Sure!
Websites use cookies to keep you logged in across pages. This just takes the cookies used by the current domain, generates a random password, encrypts those cookies with that random password, and then sends the encrypted cookies without the password off to the server.
Then, when another user goes to your access URL, the chrome extension takes the password from the URL (which is what shows up in the #), it decrypts the cookies, and then adds them to Chrome's cookie jar.
It'd be way easier honestly to just store all the cookies on the server without this encryption, but a product like this is dangerous without a lot of thought put into security. It's worth the extra effort on my part to do right by users.
@jarredsumner yeah definitely and I think lots of people will appreciate that. I was asking because of the cookies and security concerns to be honest. Thanks!
@jarredsumner@bentossell Very intresting tool ! im just shocked being conscious of the value of our cookies, and the fact it can be used for Login case .. thanks for your clear explanation !
@lasserafn chrome extension could mitm sites using access URLs via webRequest API and then the only way to get the cookies yourself is to use Wireshark or Charles w/ trusted self signed cert, but yeah not 100% solution. The 100% solution is probably a proxy, which has other issues (streaming netflix through a proxy is bad)
@lasserafn@yefim That's right - it is an easy to use tool but you cannot call it secure. Also if the web app you login allows this it is a high chance that it is open to cross site scripting and csrf attacks. Still good job! Looks like you turn a trivial hacking method to something enjoyable, at least for some folks ;)
This is a good idea but should work P2P and not hosted on your website. you're making yourself a goldmine of accounts for hackers. I think there are better ways to implement it without going through your server.
@danr_4 I'd love to find a way to make it work P2P. Fortunately, all session cookies are encrypted before reaching the server and the server never gets sent the password (not even in the logs). That means if someone did manage to get access to the database, all they'd get is a bunch of encrypted data without a way to use it. It also doesn't keep emails or any other personally identifiable information. It'd be really hard for a hacker to do anything at all with the data (or me, even)
@jarredsumner you're right. it's a good implementation, but still vulnerable to brute force attacks. I'd use a longer password (26+ chars) as it won't hurt the UX but it will immensely help against brute force attacks. But wait a second, how do you know which password is for which cookie when the only data you are passing (through the url) is the password? You can also use WebRTC to send text messages, and instead of the password being an encryption key, it could be a user identifier, and your servers sends the users details to each of the peers to create the WebRTC connections.
@danr_4 yeah I may increase the length of the password later.
It passes an ID of the session too -- and that is what gets read in from the server to know which encrypted cookie the client should receive. That ID is just a random string though (not the password)
Another thing is that these are session cookies, which often expire -- and the access URLs by default expire too. These things make it additionally more challenging from a security perspective for an attacker to make any use of this
@danr_4 webrtc is a good idea
The challenge there if I remember correctly how it works, is that then both browsers have to keep the page open for the other user to get access. That's a worse UX :(
@jarredsumner yeah but you just need to open a connection to pass the cookie as a (possibly encrypted) text message, then you can close it. so your extension launches a local web page (or even embedded in the extension window itself), you enter the user identifier, wait for a connection from the initiator, pass the cookie, and there you have it.
Just a suggestion. But this is really great, I often find myself in a situation where I need to give someone access to a sensitive site for a short time. Will use this.
EDIT: saw it takes a screenshot of the page I'm sharing. that's a bit creepy. I don't see me using it without an option to NOT take screenshots. instead there could at least be an option to have your server screenshot the homepage instead of capturing the page I'm on.
Makerpad
Covy
Makerpad
Covy
Makerpad
Valentine Roulette
Covy
Covy
Covy
Covy
Covy