We want feedback from people who are building specifications with current tools, to help us make some decisions on the final featureset of the product. We wish we could show screenshots, but the interface currently is functionality only without design :(
These tips are good practices, but they are micro-optimisations. The function strtr might be 4 times faster than str_replace, but the time saved by using strtr will represent a tiny tiny tiny portion of your script execution time.
Micro-optimisations are worth it when everything else is optimized in your application. You might get way better results by focusing on your database structure or the way you store, retrieve and cache your data.
What's listed here doesn't lead to "highly efficient code". More like "A tiny little bit more efficient code". Doesn't hurt doing it though.
Actually, these tips for PHP coding cannnot guarantee improving efficiency in every project. For different apps,some of these tips may be very useful.For example, I was involved in one of the H.264 decoder development, some of the tiny operations would be run thousands times when decoding a video clip, even a small optimization improved the peformance largely.
I recently had to choose a way to authenticate users for a prototype web app I was building. My first choice was OpenId, because the promise behind it is awesome (1 login everywhere) and I wanted to avoid depending on FB.
First annoying thing about OpenId is that most providers make an awesome job of hiding their entry point, or the exact URL that is each user ID. Except for Google, I had to extract URLs from various authentication pages (StackOverflow has a nice one) and plug-ins (http://jvance.com/pages/JQueryOpenIDPlugin.xhtml among others).
Second annoying thing about OpenId is consistency. Some providers provide a distinct URL for each user, and some have a unique URL for every users. This makes your auth form an UX nightmare where users have to paste their URL instead of just clicking a button.
Add to this the fact that each providers has it's own understanding of the spec, which leads to some weird implementations of the protocol (once again except for Google's). That and the not-so-occasional errors from several providers (these raw "Error 500 - contact our administrator" we all love).
At this point, I had spent almost 20% of the time I had to make the whole prototype, trying to figure how openId could fit in. So I changed my mind and switched to FB Connect...which can be integrated in about 20 minutes.
I'm no FB fan, really. But I have to admit it just works...
By the way, since we're on HN, there's a multi-billion dollar idea here : Create a way to add OpenId to any website, that is easy and fast to implement and friction-less for users.
The first rule of the cloud is : If you think your data requires a high level of privacy, don't store it on someone else's platform.
The second rule of the cloud is : Paying for a service to get a "private" option doesn't mean the data you store is and always will be 100% unreadable/unusable by the company providing the service. Targetted ads is based on exactly that.
Finally, the most important rule of the cloud is : If you're sad/annoyed/chocked when you realize that companies like Google, Facebook, GitHub, Dropbox, and thousands others have priorities that could conflict with yours at some point and threat your business or your privacy, just don't work with them, just don't rely on them.
Or, if your data requires a high level of privacy, encrypt it before you store it somewhere else, in a way that the storage platform can't decrypt it. E.g. tarsnap.
Being able to provide you with your password in plain text doesn't mean it's stored in plain text. There are very efficient and secure encryption algorithms that are reversible, out there.
Of course, sending passwords in an unencrypted email is bad practice, but that's another story.
'plain text' here includes encrypted non-hashed formats. Passwords should always be stored hashed so the original site (or any attacker who gets them) can get access to the password.
And if it's possible to automatically reverse the encryption, then it's not far off plain text.
More specifically, it raises the bar from requiring a database dump (SQLi) to also requiring the encryption key (filesystem access or discover it yourself by cracking weak passwords).
When each line of code you write is a point of failure, I would rather trust an algorithm (e.g. bcrypt) which is immune to all of them rather than reversible encryption which needs only two.
What do you mean by secure encryption algorithms which are reversible? Encryption implies an operation in reverse order to exist, otherwise it is in essence, digesting.
It's always (almost) completely unnecessary to store encrypted passwords.
> What do you mean by secure encryption algorithms which are reversible?
AES-256 symmetric encryption (as one example) is designed to be reversible while a SHA-512 hash is not. What does reversible mean you ask? It means that plaintext can be made into ciphertext and then back to plaintext again. It's designed to be undone/reversed by the party that holds the key/password.
Reversible does not mean the same thing that symmetric does. Encryption, by definition, is reversible. If your algorithm is not symmetric, you will not be able to decrypt it with the same key as you used to encrypt it, but it would still be reversible. If it wasn't reversible, it would be data destruction (ie, Unix shred) or hashing (ie, SHA). "Reversible encryption" is a pleonasm.
While it's possible that this is true, it's still exceptionally bad practice. Reversible encryption, particularly when stored server-side, which is almost always going to be the case, and even if using a HSM, isn't entirely different from plaintext when the attacker holds the keys.
Your idea could be very good or very bad, depending on how your service works. But right now, there is no way to tell because it shows nothing at all.
You basically asked for some feedback on the content of some <title> tags.