Tag Info

New answers tagged

9

Your proposed mechanism is not secure. Anything available to JavaScript is available to the person running the client browser. Base64 encoding only mildly obscures the answers. Even encrypting them using strong crypto like AES will not work because the JavaScript must have the key. Would someone go the trouble of figuring out the Base64, or encryption? ...


1

Basic answer: don't do that! Our current model at my employer is fundamentally flawed in my opinion Your opinion is totally correct. Storing passwords in a file like this is A Very Bad Thing. Anti-weakpasswords is also correct: the first thing you should be doing in this situation is to implement a "proper" corporate access control infrastructure. For ...


4

First off, for as much as possible you need to switch over to something like Windows Active Directory or using LDAP* for internal permissions. That way, users get permissions based on a central repository, don't know other users passwords, and you can audit who is able to - and who did - access what. I'll assume you aren't in a regulated industry (if you ...


1

This is one of those jobs best left to INFOSEC professionals. Too much to go wrong. The closest thing I've seen to what you're describing is Clipperz: https://clipperz.is/security_privacy/ Running that from a local file hardcoded with your server's I.P. address over SSL or IPsec would be a start. I agree with NDF1 that a native app is better mainly due to ...


2

The thing about a web app is it's fundamentally insecure if the source code (e.g. JavaScript) is delivered to the client over TLS. You can run the best encryption you want e.g. one-time pads or cascaded stream ciphers, but it will only be as secure as the ciphers and "security" in the TLS suite which is not secure against spy agencies. There have been ...


5

One thing not mentioned yet: fake data that is otherwise never used. If you ever encounter that information, your data leaked. In how far this is practically useful depends on the data. A login attempt for a specific user name is a good example, because that kind of leaked data is likely to surface.


14

The number of security measures in place and the capabilities to discover breaches will vary widely from company to company and depends on the type of data that is stolen. There are several ways a company will learn of a breach: security sofware catches unusal behaviour and marks it for later review (or stops it on the fly after part of the data ...


2

It is very possible that smaller companies never know that they've been compromised. After all, how much do they pay for their applications? The larger ones have the benefit of law enforcement getting in touch, but everyone else just has to live with misfortune.


2

There's no security reason why you can't hash the password manually and compare using an SQL statement. There are non-security reasons to do so, though. SELECT hashed_password FROM users WHERE userid=? Retrieving the hashed password from the database and comparing in code only requires a single database access. SELECT salt FROM users WHERE userid=? ...


3

Best practice is to used salted hashes for password. Comparing two salted hashes involves removing the salt from the stored password, appending to the clear-text password and rehashing and comparing equality. Because of this, it is not something that could easily be part of a SQL WHERE statement. While I suppose this could be implemented at the DB layer, ...


1

What you keep about the user is your own decision. The most basic implementation is keeping a user ID (the one received from the open ID provider) and the token you receive from the open ID provider (which includes access token, expiration and refresh token). whatever you wish to keep beyond that is up to you. As much as I know every openid connect ...


0

The best answer to "How can I monitor SQL queries" is to ask the SQL Server administrator to run Profiler. However, failing that, on the machine you are a legitimate administrator on, you could run the app and a tool to look at your machine's RAM, the simplest example I know of being a simple Hex editor like HxD. You can also use that same utility or a ...


1

I will first address the various attack vectors possible if the device is on or off and whether full disk encryption (FDE) is on or off. After that, I want to comment about the need for app-level encryption and the capabilities that it offers in your particular scenario. Here, we assume the attacker has obtained control of the device. Furthermore, we ...


0

You don't try to hide them. Anyone with access to the application and sufficient incentive will be able to find the credentials. So what do you do instead? It all depends on what you're trying to restrict. If it's an app for anyone to download and use then you may not need any credentials. A step up from that would be to generate and store a security token ...


1

What is your threat model? Always answer that first. It looks like existing data is probably safe (given most reasonable threat models). However, you are as strong as your weakest link. The front-facing servers still have to hold onto the data during processing. Does your threat model include a hacker that compromises that server and simply begins ...


0

I have a wild guess how the hacker accessed your configuration file. You might have edited it recently; and the PHP temp files during or after edit are remained on the directory where the config file was stored. check if you can access .php~ php# php.save php.swp php.swo These are the temporary filenames used by the most popular text editors. Or ...


1

Your question can not be answered with the given information. From what we know you might not even been hacked at all. You might start with telling us more about those queries and what do you mean by directly into the database. Remote access from other IP address or a query you can't find in your scripts? Those query might be from Laravel or a plugin. ...


0

Looks like there are some known vulnerabilities that might have been their starting point. V4 had a CSRF issue in November for example. I agree with the commenter who said that step one is changing your database auth details. http://blog.laravel.com/csrf-vulnerability-in-laravel-4/


1

Yes, there are a variety of risks or risk increases here. First and foremost, whether or not your DBA's can be trusted, they should be able to honestly tell any auditor (or regulatory investigator, or lawyer) that no, it is not possible that they impersonated user X, because they were never, ever able to see user X's password even if they wanted to, and ...


4

Yeah, this is the price you pay for cut rate SQL hosting. It's not the end of the world, but you get what you pay for. The idea of Security Through Obscurity is usually considered a bad practice when relied upon on it's own. Rather it's a better idea to secure systems as if an attacker had full visibility of how things are setup. It's also important to ...



Top 50 recent answers are included