meta user
network profile
| bio | website | php100.wordpress.com |
|---|---|---|
| location | San Jose, CA | |
| age | 38 | |
| visits | member for | 2 years, 5 months |
| seen | Mar 31 at 7:43 | |
| stats | profile views | 31 |
Programmer (Unix, Windows, C, C++, PHP, etc.)
|
Dec 31 |
comment |
What is your way to create good passwords that can actually be remembered? the problem with this method, once you forget was it "add @@ in the front, $$ in the back, shift 1 to the left and 2 down with wrap" or "add ## to the back, 12 at the front, shift 2 to the right with wrap and 1 down without wrap" you have a problem :) And sometimes you need passwords to places you last visited 4 years ago... |
|
Dec 31 |
comment |
What prevents this exploit from working (unix SUID)? Actually, you can set the SUID bit. You can't make it SUID to another user though, if you're not root. |
|
Dec 31 |
comment |
Disable insecure/dangerous PHP functions IMHO this is an exercise in futility. If somebody gains access to your system allowing him to run arbitrary PHP code on your system, disabling functions not going to help. There are dozens on functions not listed which can be used this way. Actually, this list makes zero sense - mysql_pconnect is there but mysql_connect and mysqli_connect are not. |
|
Dec 29 |
comment |
Why do people say that PHP is inherently insecure? @Ams of course there are (were) vulnerabilities, as in any other software big and popular enough. This however in no way means some "inherent insecurity". |
|
Dec 25 |
comment |
Storing third-party auth info securely There is a good reason. This is a service that users ask for, which works with their email data. I'm not sure I can reveal the details of what is done with the data, but they are mostly irrelevant - if you are concerned that the users don't know about what is involved, or somehow getting taken advantage of - it is not so. I'm not sure why you mention spam - it has absolutely nothing to do with spam. |
|
Dec 25 |
comment |
Whitelisting DOM elements to defeat XSS The same way - XSS site vulnerability. Imagine site that prints title (which is in the head section) according to user input and forgets to validate... Also, it may manipulate DOM to inject stuff into head section - so you'd have to introduce DOM permissions. And what if there's some vulnerable page that doesn't have <HEAD> elements at all - like one generating JSON? I could supply my own <HEAD> and thus break the protection. |
|
Dec 24 |
comment |
Storing third-party auth info securely honeypots isn't a bad idea, though it wouldn't help with the original problem. |
|
Dec 24 |
comment |
Storing third-party auth info securely The problem is it has to be persistent - i.e. the app should have access to the account in a week, month, etc. I.e. storing the key in memory wouldn't solve it - what if the server restarts, how would it decode the info then? Asking the user is not an option, that's the whole problem - the system should be independent once the user has registered the account. |
|
Dec 24 |
comment |
Why do people say that PHP is inherently insecure? This is untrue. PHP does have a lot of hacks, but it has nothing to do with insecurity. Any complex program has bugs, some of them would be security-related, so pointing to the list of bugs as proof of "inherent insecurity" is pointless and misleading. |
