Tag Info

New answers tagged

1

Yes, however, this is a common pattern. For example, this is how reddit's authentication works and Instagram's. Frankly, the only thing it protects against is sending your password over the network in plaintext. But the process does expose your session and all of your browsing data over HTTP, which just means your session has the same strength as HTTP. A ...


1

This can very well be a concern. Different browsers handle it different ways. Chrome passwords on Windows are not stored in some file in AppData; they're stored using Windows's DPAPI, which means that they're encrypted with a key derived from your Windows password, so they're secure if someone doesn't have access to your Windows account. However, while it's ...


0

I think that what he is trying to say is that you should not keep all the keys in the same place. The compartmentalization of the process is what plays the key role in the auth mechanism he suggests. One thing that you should also keep note is to take benefit from the Same Origin Policy. Using SOP will prevent attackers from manipulating data from a domain ...


2

Send a request to a server you control and see it it was altered in transit; you may also use a online service like HTTPBin, it's designed to test HTTP client libraries and has pages that return the exact request content, so you'll see if additional cookies were added. Note that ISPs can be sneaky about this and only add the cookies in requests to their ...


6

"The attacker registers a domain (such as attacker.com) and delegates it to a DNS server he controls. The server is configured to respond with a very short time to live (TTL) record, preventing the response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the ...


0

By trial and error I found the answer: It seems that when SSL is used (test 2), setcookie is required as follows: setcookie('sessionname', session_id(), time()+whatever, '/', 'theSSLhostaddress', true, true or false); Also, the htaccess works in test 2. The non-SSL script (test 1) did not require setcookie! Hope this helps.


3

Cookies are domain-dependent. You don't decide, from the server side, which cookie you read; the browser sends the stored cookies that match the name (with domain) of the target server. If you want to share some authentication in some SSO manner, then you need both servers A and B to delegate the authentication to a common third server C. That server will ...


4

Unless "website A" and "website B" are both subdomains of the same domain, what you want to do is impossible; if they are subdomains of the same domain, the same person or organization presumably controls both. Consequently, legality is irrelevant.


0

If you are passing authorisation token via http headers then you need to have a client side logic to pass this to server every time you make a request. A skimmer can look for this in your client side code and can hijack your user session with Java script. But if the same info is passed via cookies then it is the browsers responsibility to pass the cookie ...



Top 50 recent answers are included