| bio | website | martinstoeckli.ch |
|---|---|---|
| location | Switzerland | |
| age | 40 | |
| visits | member for | 1 year, 3 months |
| seen | 9 hours ago | |
| stats | profile views | 122 |
I belong to the lucky people, who can combine job and hobby, in my case writing software. Coming from the Delphi world, i'm working more and more with CSharp and use PHP for my spare time project, an internet lost-and-found office.
|
Jun 13 |
comment |
Which encoding/decoding is used? That's true, but an encoding that makes 12 characters out of 1 or 2 seems very inefficient. |
|
Jun 13 |
comment |
Which encoding/decoding is used? Why do you think it is an encoding? For me it looks more like encryption or some kind of hashing. Where did you get those values from? |
|
Jun 7 |
comment |
Password on login idea One more thought about shoulder-surfing: Too complex instructions will be difficult to fulfill, when you don't see what you are doing (because of the ******* in the input field). The alternative of showing the password will of course decrease security. |
|
May 6 |
comment |
Safe to connect to external drive? Knowing that it doesn't answer your question, Windows users can hold down the <shift> key, until after the drive is mounted, this should prevent any autoplay and autorun scripts. |
|
May 2 |
comment |
Could a password hash that's prone to more collisions provide better overall security? @Johnny - I bet that you would be able to pick the real password in 99% of all cases, because most people do not choose absolutely random passwords. It may be more difficult for a computer to choose the right one, but i'm sure one could write software that can do a rating and find the most probable ones. |
|
Apr 26 |
comment |
Is there any SQL injection for this PHP login example? @TildalWave - Congratulations, you gained the endless patience award! |
|
Apr 5 |
comment |
Encrypting short identifiers? @TildalWave - Yes, it seems that he will never be able to change his avatar :-). |
|
Apr 5 |
comment |
Encrypting short identifiers? @TildalWave - I think a hash doesn't solve the problem. It would be convenient to have a function that encrypts the (auto-incremented) primary key of a database row, so you can find the row again. The encryption doesn't need to be strong, it should just obfuscate the primary key. And with a generated random key, you would need to check if such a key already exists. |
|
Mar 13 |
comment |
how to find injected code in SQL Did you find the original problem, making SQL-injection possible at first place? |
|
Mar 8 |
comment |
Extended validation SSL certificates @user2119955 - Maybe you missed Ladadadada's point about EV-certificates. He wanted to point out, that there is a difference between domain-validated and extended-validation certificates, and that even Google uses the cheaper domain-validated certificate, because it's technically the same. |
|
Mar 8 |
comment |
Extended validation SSL certificates Some providers offer to use their own certificate for free. The URL to request a page would in this case look like this: http://yourdomain.providerdomain.com. Not sure if that is an option for you, but is is surely the cheapest one. |
|
Mar 4 |
comment |
Client-Side Hashing to decrease value of password guessing heuristics I think this meets exactly the question. One can imagine that an attacker just writes code that first makes the client-side hashing, and afterwards the server-side hashing. The input is still the weak password then and not the sent hash. |
|
Mar 3 |
comment |
Is it inconsistent to tell users to “not click on password links in email”, and requiring clicks on “forgot password” links? Password reset links are expected, you will only click the link if you have demanded such an email before. That's a rule everybody should be able to understand. |
|
Feb 8 |
comment |
How can I constrain or limit 3rd party Javascript (*.js) files that can DOS my site? @drjimbob - Thanks for the clarification. |
|
Jan 23 |
comment |
is it easier to get the original password if you have multiple hashes of it? @sujeesh - Actually the OP knows that one can brute-force the weakest hash value. I think his question was, whether combining the different hashes may give an advantage. |
|
Jan 23 |
comment |
is it easier to get the original password if you have multiple hashes of it? I think the OP's scenarion was more, that a user reused the same password on several sites, and the attacker got access to those different hashes (not calculating several hashes on the same CPU). But your first part answers the question i think. |
|
Jan 11 |
comment |
In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - The stored salt is plain text, it is not hashed itself. You can just look for the signature $2y$10$ and the next 22 characters are the used salt, you can reuse it to calculate the new hash. In contrast to password_hash(), the function password_verify() does not create it's own salt, it uses the extracted salt from the stored hash-value. |
|
Jan 11 |
comment |
In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - What i tried to explain is, that the salt is part of the generated hash-value. The password_verify() gets the entered password and the stored hash-value from the database, and can extract the salt from the stored hash-value. Then it calculates the hash of the entered password, with the same salt it used to calculate the stored hash-value. Now it can compare the hash-values, because they are based on the same salt. |
|
Jan 11 |
comment |
In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - The part 2y is the algorithm BCrypt, the part 11 is the cost factor and the next 22 characters are the salt. The rest after the salt is the actual hash-value. The whole string can be stored in the database, and when you verify the password these parameters are extracted from the stored hash-value to hash the entered password. Have a look at the bottom of this page for an example. |
|
Jan 11 |
comment |
In this example why do they hash a randomly generated piece of salt before hashing it with the password? @Celeritas - Yes, each password gets it's own salt, therefore equal passwords get different hash-values. To check if the password matches the hash-value, you use the function password_verify() instead, here you can find an example. |