Tag Info

New answers tagged

0

No, you can not do that legally. If you want to be sure, you can use a packet analyzer like Wireshark. Or you can also use Anti-virus/Privacy tool or Phishing detectors. You can check the code of application. At last, you can also switch off your internet to see the error message and confirm which link could not be loaded(or if it loads without error, that ...


2

As for the title of your question: your communication channel is encrypted by TLS. That part is OK. The body of the question is actually about authentication. You have a few options, the main ones being: reuse the client certificates your users already have (due to the way you set up encryption by requesting both client and server certificates). Depending ...


1

I think the security threats come from a few places: Data accessed by IFTTT. An attack can happen in transit, in memory, or in storage (for a security evaluation I'll assume that IFTTT stores all data it accesses). Accounts and devices connected to IFTTT. While you're recipes may not access sensitive data, if IFTTT has access due to mobile app ...


0

There may not be a justification "security wise", but there are other design considerations which are worth exploring. In my opinion, the biggest advantage of using OAuth is that you abstract the authentication method from the various systems required authentication/authorisation (this is something tylerl was describing). As an example: you start off with ...


0

The advantage of OAuth over password-based login is that OAuth allows me to give you limited permission to use my identity without telling you my password. So say your site posts messages to Twitter using my account. I want to give you permission to use my account to post a tweet, but I don't want to give you unlimited access to my Twitter account -- I ...


3

It is true that bearer tokens and session tokens should not be passed int he url. The reasons are (according to OWASP): might disclose the session ID (in web links and logs, web browser history and bookmarks, the Referer header or search engines) In this specific case, I think Facebook did not care since the usage is logout - so after it has been ...


1

It could be that the access token might end up being used around the application over plain HTTP connections. So if an attacker sniffed it, they would only have short term access. This is what used to happen on the web as standard. Login was over HTTPS if you were lucky, and the rest of your session was over plain HTTP, transmitting the session ID in ...



Top 50 recent answers are included