Jump to content

Jacques1

Members
  • Content Count

    4,207
  • Joined

  • Last visited

  • Days Won

    208

Jacques1 last won the day on February 3 2018

Jacques1 had the most liked content!

Community Reputation

628 Excellent

1 Follower

About Jacques1

  • Rank
    Turtles all the way down

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

51,172 profile views
  1. The ugly truth is that's it's practically impossible not to leak this information. Even if you show the same message, anybody can easily tell the difference between the two execution paths by comparing the response times. Since modern password hash algorithms are expensive by design, there will be noticable difference between an invalid e-mail address (which is instantly recognized) and an invalid password (which requires the server to compute the hash). You can make such attacks harder by designing the system appropriately, but this requires a lot of work, experience and complexity. A
  2. All versions up to and including 5.5 have already reached end of life, so the password API should now be available in all common setups. If the server runs some kind of long-term-support version, there's a compatibility library which works exactly like the API but supports PHP versions down to 5.3. Sure. I just have my doubts as to whether this is really helpful. Threads in a forum like this generally don't age well, because there's no proper mechanism for keeping them up to date or at least downvoting them (like on SO). You'll find the same problem – and much worse advice – in
  3. The implementation is not secure. First off, UUIDs are not meant for security purposes, and there's no guarantee whatsoever that they're difficult to guess. The only promise is that they're unique (with a reasonably high probability). Some UUID implementations do use secure random numbers, but others are simply time-based. EIther way, using constant plaintext IDs as authenticators is the worst possible choice, because anybody who manages to obtain the IDs effectively gets unlimited access to the accounts. This is even worse than plaintext passwords, because passwords can at least be ch
  4. Guys. I understand that PHP people love to turn simple problems into fugly hacks with lots of bugs, but let's not be ridiculous. This is JSON. PHP knows JSON. Turning an array into a JSON document takes one function call. One. No loops, no string fumbling, no comma gymnastics. One function call. Writing this down is a matter of, say, 30 seconds including a quick check of the manual. Instead, you've already spent an hour banging your head against the wall. Even as a non-programmer, you should be able to see that this is not very smart.
  5. Do you have a reason for that, or do you just like to waste your time on useless, buggy code? Because if it's the latter, it looks like you've already achieved your goal.
  6. Looks like you're trying to generate JSON documents by hand. Don't do that. PHP is perfectly capable of doing that itself -- properly.
  7. PHP says otherwise, and I'm inclined to believe it rather than you. The error message tells you exactly where the output started. Open that file and check the line. If you cannot see anything that would generate output, open the file in a hex editor. Maybe there are hidden characters like a byte order mark. No. As I already said, this is a hack, not an actual solution. The solution is to get rid of the output.
  8. A quick Google search will tell you that this is one of the classical PHP mistakes. The simple answer: You must not generate any output before calling session_start(). No HTML, not even blank space, nothing. Starting a session involves sending a cookie, but this isn't possible when you've already sent the HTTP response (and therefore the headers) to the client. So make sure the session_start() happens before that. If the code worked before, my guess is that you lied about the “nothing has changed” and actually deactivated output buffering. Either way, the proper solution is to get rid
  9. If I got a dollar every time somebody says this, I would be a rich man. I don't know what kind of college is this, but my professors actually checked my work and would have immediately rejected a submission which doesn't even survive the most basic tests. This is not just wrong. It shows a fundamental misunderstand of programming basics.
  10. This script will delete anything the user asks for as long as the webserver has permissions to do so. Since a lot of web applications are both running under and owned by the same webserver account, this means a user can probably wipe your entire document root – and maybe more. Do – not – trust – user – input. Do not let it anywhere near a file path, unless you've extensively validated the input and made sure it's harmless. Using GET requests to delete data is also a very bad idea, because this violates the HTTP protocol. GET is strictly for getting data (hence the name) and mustn't have an
  11. This may disappoint you, but none of us is a mind reader. We cannot identify the API you're using just by looking at the words “NULL bool(true)”, and we aren't able to deduce the inner workings of that API from this piece of (non-)information. Sure, it would make life a lot easier, but unfortunately, we're mere mortals. Any halfway professional API is extensively documented (if yours isn't, look for an alternative). So the first step is to RTFM. Have you done that? The authentication procedure will involve credentials like an API key which you've received during the registration procedure
  12. I didn't even get to the topic of security. The point is that the code is broken on every single level and one of the worst possible choices you could have made. If you simply accepted that half of the features will never work and the other half will randomly crash, sure, you could do that. But you're obviously here to get this stuff fixed, and I'm telling you that's hopeless.
  13. His reply contained more useful information than any other resource you've learned/copypasted from so far. When you're completely new to a topic, it's a good idea to actually listen to those who know what they're talking about. Whether you like to hear it or not, the code you've chosen is amateur crap which is at least 13 years out of date and hasn't been updated in the last 6 years. As soon as your hoster decides to update the PHP version (the 5.x branch has already reached the end of active support), the whole application will cease to function.
  14. Create a string first. When that's done, you can take care of writing the string to a file. I hope the columns aren't literally named “info1”, “info2”, “info3”?
  15. Yes, it's common practice to spend all day long trying to come up with the most obscure solution to an imaginary problem. However, your approach is not optimal. You should foo the bar into the baz, then bla the baz together the qux until the garply is ready.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.