Tag Info

New answers tagged

2

No, it's not secure, and it seems unnecessary complex. In particular: No reason to encrypt tokens on a database level. If an attacker can get password hash (has access to DB), he can get brand new tokens. No session expiration described. This can help: OWASP REST Security Cheat Sheet, Authentication Cheat Sheet


4

It is impossible to prevent this issue from happening completely. There are two things you can do that will help but not completely migrate the problem: Use SSL only: If you control both the client and the server than there is no reason you can't encrypt the traffic, this prevents people from sniffing out your API calls by studying your traffic - it also ...


1

There is NO reliable way at all to do what you want. Why not? Because ultimately you would be relying on information provided to you by 3rd parties. So if a user provides an email adress, you are going to contact the mailhost of said email adress. How can you know that the user is not the server admin of the email server and provides you false information? ...


2

The main technical reason is that most databases require you to authenticate in order to figure out which "schema" or "application" you are connecting to. Otherwise, it doesn't know who you are. The main security reason is that connections from the local network should not be trusted. If another node on your network is compromised (a PC, a server, a wifi ...


2

You would use that feature to log into the database. Your program (whether it runs on the server or the client) is going to have to identify and authenticate itself--either to the (MongoDB) database itself, or possibly to a proxy service. In either case, it will need at least a userid and password to do so. (Cryptographic keys or trusted tokens are even ...


1

That is how HornetQ's websocket implementation works (Stomp doesn't necessarily have to work over WebSockets but HornetQ exposes both naked TCP and WebSocket options). StompConnection.java Essentially the connection object is wrapped with the metadata of the HornetQ session ID and the login credentials and flagged "isValid". So yes, it's certainly a ...


3

The situation that you are referring to would happen if the client is compromised. This is a real concern, but in that case any protection that you implement is trivially bypassable by having the compromised client do whatever needs to be done. So you can do an IP address check, but it won't actually help much. That said, the data structure that you have ...



Top 50 recent answers are included