Tag Info

New answers tagged

1

If an OAuth 2.0 token is compromised, you only need to concern yourself for the TTL of the token. If an HTTP Basic Auth header is compromised, the credentials do not expire. You would manually need to change your client_id and secret, and that's if you even knew or thought they were compromised. And it's likely you would need to change your client code ...


2

What I would say about the options that you outline is that HTTP Auth with SSL is a simpler but less flexible option and Oauth2 is more complex but has more flexibility in what you can achieve with it. One example, as you've noted in your ASCII art diagram, with OAuth2 it is possible to create a token which can be used in place of the password to ...


0

No, because SQL Injection and Insecure Direct Object References includes the case of 'ability to run SQL that the user has access to but the application was designed to not allow'. Your method will limit the ability to get at stuff outside their permissions, but in most cases that includes things that aren't intended to be open, as well as system ...


1

Not effectively, no. You're always going to have cases where row-level security can't properly emulate the business processes. You'd also need to have a lot of "general purpose" accounts for things like user signup. The whole thing would be convoluted, difficult to maintain, and largely ineffective. Keep in mind, also, that SQL injection potentially does ...


2

Protecting the root account makes cleanup much easier: if an attacker can't tamper with the kernel or most of the programs, it's much harder to hide malicious code. It also means they can't tamper with the antivirus and other protection systems.


1

I think it is fine to have a web facing panel as long as: Its not guessable, for example, www.example.com/admin. U don't want notorious users to attempt brute-forcing for two reasons: Incase the brute-force succeeds. If u have an account lockout policy in place, which you should, u don't want to be locked out by notorious users. Use strong passwords ...


0

For low value sites, username and password is ok. There are a lot of sites that are just not worth hacking into, and where the risk/cost of compromise to you is fairly minimal compared to the cost of securing it. For most sites though, you should require the use of HTTPS or VPN when doing administrative functions. There are now some SSL certificate ...


0

Lot of applications relies on a simple username/password combination. This is not the technique that you should worry about, but how you implement it. You need to make sure that passwords are strong enough not to be guessed. They should not be stored in plain-text in your database in case it gets compromised. Furthermore, you want to avoid interception of ...



Top 50 recent answers are included