I implement multiple-factor authentication systems for a living, so for me it is natural to think that you can either reset or reconstruct the password, while temporarily using one less factor to authenticate the user for just the reset/recreation workflow. Particularly the use of OTPs (one-time passwords) as some of the additional factors, mitigates much of the risk if the time window is short for the suggested workflow. We’ve implemented software OTP generators for smartphones (that most users already carry with themselves all day) with great success. Before complains of a commercial plug appear, what I’m saying is that we can lower the risks inherent of keeping passwords easily retrievable or resettable when they aren’t the only factor used to authenticate an user. I concede that for the password reuse among sites scenarios the situation is still not pretty, as the user will insist to have the original password because he/she wants to open up the other sites too, but you can try to deliver the reconstructed password in the safest possible way (htpps and discreet appearance on the html).

NOTE: This answer was originally posted at StackOverflow.com by Monoman

I work on miniOrm. Just a mini ORM, for using Object Model & MySQL Abstraction Layer as simply as possible. Hope it may help you : http://jelnivo.fr/miniOrm/

NOTE: This answer was originally posted at StackOverflow.com by Cédric Mouleyre

NotORM

include "NotORM.php";
 $pdo = new PDO("mysql:dbname=software");
 $db = new NotORM($pdo);
 $applications = $db->application()
->select("id, title")
->where("web LIKE ?", "http://%")
->order("title")
->limit(10)
;
foreach ($applications as $id => $application) {
echo "$application[title]\n";
}

NOTE: This answer was originally posted at StackOverflow.com by Charlie Chai

Agile Toolkit has its own unique implementation of ORM/ActiveRecord and dynamic SQL.

Introduction: http://agiletoolkit.org/intro/1

Syntax (Active Record):

$emp=$this->add('Model_Employee');
$emp['name']='John';
$emp['salary']=500;
$emp->save();

Syntax (Dynamic SQL):

$result = $emp->count()->where('salary','>',400)->getOne();

While Dynamic SQL and Active Record/ORM is usable directly, Agile Toolkit further integrates them with User Interface and jQuery UI. This is similar to JSF but written in pure PHP.

$this->add('CRUD')->setModel('Employee');

This will display AJAXified CRUD with for Employee model.

NOTE: This answer was originally posted at StackOverflow.com by romaninsh

Brazilian ORM: http://www.hufersil.com.br/lumine. It works with PHP 5.2+. In my opinion, it is the best choice for Portuguese and Brazilian people, because it has easy-to-understand documentation and a lot of examples for download.

NOTE: This answer was originally posted at StackOverflow.com by Paulo Araujo

MicroMVC has a 13 KB ORM that only relies on a 8 KB database class. It also returns all results as ORM objects themselves and uses late static binding to avoid embedding information about the current object’s table and meta data into each object. This results in the cheapest ORM overhead there is.

It works with MySQL, PostgreSQL, and SQLite.

NOTE: This answer was originally posted at StackOverflow.com by Xeoncross

WordPress 2.7 lets you upload a zip file directly (there’s a link at the bottom of the plugins page) — no FTP access needed. This is a new feature in 2.7, and it works for plugins only (not themes yet).

NOTE: This answer was originally posted at StackOverflow.com by D. Lambert

Hmm. Too bad nobody said symphony yet.

The only reason to use wordpress is the nice looking admin interface, the code is poorly written and only pointed at blogs. It is possible to use WP as a ‘real’ cms, but not without hacking the core, or hacking away in templates.

NOTE: This answer was originally posted at StackOverflow.com by creativedutchmen

This post is somewhat old, but I just found it today (12-19-2011).
The first CMS I found was Joomla, which I felt was great for a very short time. Dupral, evern shorter. Joomla is a click this, click that nightmare, and really doesnt offer much more than wordpress. Dupral is a clone, so I really see no point in using it.

Ultimately I used Wordpress for numerous sites, ranging from photo galleries to eCommerce sites. And the sites have performed well, for years.
Most clients are concerned with appearance, and the ones who do make their own changes have no problem using wordpress.

But now I am seeking something “better”? Something that allows more design flexability. Something I can do more with. Plus I have yet to find a Wordpress utility for making custom themes that actually look custom. Artisteer generates themes, but what can I say, they all look alike.

I recently tried Concrete5, and its ok, but still not a developers dream solution.
Next I plan to try several of the other CMSs listed on this page, with hopes to find something that will work for both me, and the end user. So if such a beast exists, I will capture it, and never look back. Then again, Id have to say, Wordpress will be around for a long time.

NOTE: This answer was originally posted at StackOverflow.com by Vee

If you want to know more CMS, your can visit this website: CMS Matrix. You’ll found a a lot.

Wordpress does fit simple CMS requirement, simple usage, friendly user interface, and easy to extends. Be careful when choosing CMS, some of them may have too many feature and too complex for simple use.

I was once setup a typo3, and failed to teach user how to use it. Then I move to wordpress.

NOTE: This answer was originally posted at StackOverflow.com by Dennis Cheung

As mentioned Umbraco is a really good and capable open source ASP.NET CMS. v4 (which just hit beta 2) has some really nice features including in-page editing and a neat package repository. The API does leave a bit to be desired if you want to do my code interaction but I’m working on resolving this with a project of my own.

NOTE: This answer was originally posted at StackOverflow.com by Slace

I haven’t really tried it yet, but since you said your preferred platform was ASP.Net, you could always check out umbraco.

NOTE: This answer was originally posted at StackOverflow.com by andy

If you can code and you’re at all open to learning a new language and framework, you should give Django some serious consideration.

Some of the time, you might find yourself reinventing the wheel, and yes, there is some learning overhead, but it’s a really serious contender for “The next big thing”.

It’s major feature (over similar frameworks) is the automatically-generated admin area, which, if your models are logical enough, can be client-ready without any intervention from you. Of course you’re more than able to customise things to help clients.

NOTE: This answer was originally posted at StackOverflow.com by Oli

I believe, like many other posters here, that WordPress is a CMS by definition of what it can do/does. A limited CMS maybe, but most clients that I build WordPress sites for would never come anywhere near those limitations.

In my experience, it has worked well for me as an extensible, customisable, simple CMS for most client sites.

NOTE: This answer was originally posted at StackOverflow.com by davemac

WordPress is a CMS, but it’s perhaps best used when your content is effectively like a blog. For small sites that you have to hand over to clients, it’s ideal, since the user interface is very easy to use.

NOTE: This answer was originally posted at StackOverflow.com by Philip Morton

Yes as CMS = Content Managed System which is exactly what wordpress does, allows you to manage content on multiple pages of varying types. Yes it may be specialised for blogging although as you’ve pointed out this can be easily manipulated for other means.

NOTE: This answer was originally posted at StackOverflow.com by Toby Mills

Bitwise Operator

What is a bit? A bit is a representation of 1 or 0. Basically OFF(0) and ON(1)

What is a byte? A byte is made up of 8 bits and the highest value of a byte is 255, which would mean every bit is set. We will look at why a byte’s maximum value is 255.

-------------------------------------------
|      1 Byte ( 8 bits )                  |
-------------------------------------------
|Place Value | 128| 64| 32| 16| 8| 4| 2| 1|     
-------------------------------------------

This representation of 1 Byte

1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 = 255 (1 Byte)

A few examples for better understanding

The “AND” operator: &

$a =  9;
$b = 10;
echo $a & $b;

This would output the number 8. Why? Well let’s see using our table example.

-------------------------------------------
|      1 Byte ( 8 bits )                  |
-------------------------------------------
|Place Value | 128| 64| 32| 16| 8| 4| 2| 1|     
-------------------------------------------
|      $a    |   0|  0|  0|  0| 1| 0| 0| 1|    
-------------------------------------------
|      $b    |   0|  0|  0|  0| 1| 0| 1| 0|
------------------------------------------- 

So you can see from the table the only bit they share together is the 8 bit.

Second example

$a =  36;
$b = 103;
echo $a & $b; // This would output the number 36.
$a = 00100100
$b = 01100111

The two shared bits are 32 and 4, which when added together return 36.

The “Or” operator: |

$a =  9;
$b = 10;
echo $a | $b;

This would output the number 11. Why?

$a = 00001001
$b = 00001010

You will notice that we have 3 bits set, in the 8, 2, and 1 columns. Add those up: 8+2+1=11.

NOTE: This answer was originally posted at StackOverflow.com by Ankur Saxena

Pursuant to the comment I made on the question:
One important point has been very glossed over by nearly everyone… My initial reaction was very similar to @Michael Brooks, till I realized, like @stefanw, that the issue here is broken requirements, but these are what they are.
But then, it occured to me that that might not even be the case! The missing point here, is the unspoken value of the application’s assets. Simply speaking, for a low value system, a fully secure authentication mechanism, with all the process involved, would be overkill, and the wrong security choice.
Obviously, for a bank, the “best practices” are a must, and there is no way to ethically violate CWE-257. But it’s easy to think of low value systems where it’s just not worth it (but a simple password is still required).

It’s important to remember, true security expertise is in finding appropriate tradeoffs, NOT in dogmatically spouting the “Best Practices” that anyone can read online.

As such, I suggest another solution:
Depending on the value of the system, and ONLY IF the system is appropriately low-value with no “expensive” asset (the identity itself, included), AND there are valid business requirements that make proper process impossible (or sufficiently difficult/expensive), AND the client is made aware of all the caveats…
Then it could be appropriate to simply allow reversible encryption, with no special hoops to jump through.
I am stopping just short of saying not to bother with encryption at all, because it is very simple/cheap to implement (even considering passible key management), and it DOES provide SOME protection (more than the cost of implementing it). Also, its worth looking at how to provide the user with the original password, whether via email, displaying on the screen, etc.
Since the assumption here is that the value of the stolen password (even in aggregate) is quite low, any of these solutions can be valid.

Since there is a lively discussion going on, actually SEVERAL lively discussions, in the different posts and seperate comment threads, I will add some clarifications, and respond to some of the very good points that have been raised elsewhere here.

To start, I think it’s clear to everyone here that allowing the user’s original password to be retrieved, is Bad Practice, and generally Not A Good Idea. That is not at all under dispute…
Further, I will emphasize that in many, nay MOST, situations – it’s really wrong, even foul, nasty, AND ugly.

However, the crux of the question is around the principle, IS there any situation where it might not be necessary to forbid this, and if so, how to do so in the most correct manner appropriate to the situation.

Now, as @Thomas, @sfussenegger and few others mentioned, the only proper way to answer that question, is to do a thorough risk analysis of any given (or hypothetical) situation, to understand what’s at stake, how much it’s worth to protect, and what other mitigations are in play to afford that protection.
No, it is NOT a buzzword, this is one of the basic, most important tools for a real-live security professional. Best practices are good up to a point (usually as guidelines for the inexperienced and the hacks), after that point thoughtful risk analysis takes over.

Y’know, it’s funny – I always considered myself one of the security fanatics, and somehow I’m on the opposite side of those so-called “Security Experts”… Well, truth is – because I’m a fanatic, and an actual real-life security expert – I do not believe in spouting “Best Practice” dogma (or CWEs) WITHOUT that all-important risk analysis.
“Beware the security zealot who is quick to apply everything in their tool belt without knowing what the actual issue is they are defending against. More security doesn’t necessarily equate to good security.”
Risk analysis, and true security fanatics, would point to a smarter, value/risk -based tradeoff, based on risk, potential loss, possible threats, complementary mitigations, etc. Any “Security Expert” that cannot point to sound risk analysis as the basis for their recommendations, or support logical tradeoffs, but would instead prefer to spout dogma and CWEs without even understanding how to perform a risk analysis, are naught but Security Hacks, and their Expertise is not worth the toilet paper they printed it on.

Indeed, that is how we get the ridiculousness that is Airport Security.

But before we talk about the appropriate tradeoffs to make in THIS SITUATION, let’s take a look at the apparent risks (apparent, because we don’t have all the background information on this situation, we are all hypothesizing – since the question is what hypothetical situation might there be…)
Let’s assume a LOW-VALUE system, yet not so trival that it’s public access – the system owner wants to prevent casual impersonation, yet “high” security is not as paramount as ease of use. (Yes, it is a legitimate tradeoff to ACCEPT the risk that any proficient script-kiddie can hack the site… Wait, isn’t APT in vogue now…?)
Just for example, let’s say I’m arranging a simple site for a large family gathering, allowing everyone to brainstorm on where we want to go on our camping trip this year. I’m less worried about some anonymous hacker, or even Cousin Fred squeezing in repeated suggestions to go back to Lake Wantanamanabikiliki, as I am about Aunt Erma not being able to logon when she needs to. Now, Aunt Erma, being a nuclear physicist, isn’t very good at remembering passwords, or even with using computers at all… So I want to remove all friction possible for her. Again, I’m NOT worried about hacks, I just dont want silly mistakes of wrong login – I want to know who is coming, and what they want.

Anyway.
So what are our main risks here, if we symmetrically encrypt passwords, instead of using a one-way hash?

• Impersonating users? No, I’ve already accepted that risk, not interesting.
• Evil administrator? Well, maybe… But again, I dont care if someone can impersonate another user, INTERNAL or no… and anyway a malicious admin is gonna get your password no matter what – if your admin’s gone bad, its game over anyway.
• Another issue that’s been raised, is the identity is actually shared between several systems. Ah! This is a very interesting risk, that requires a closer look.
  Let me start by asserting that it’s not the actual identity thats shared, rather the proof, or the authentication credential. Okay, since a shared password will effectively allow me entrance to another system (say, my bank account, or gmail), this is effectively the same identity, so it’s just semantics… Except that it’s not. Identity is managed seperately by each system, in this scenario (though there might be third party id systems, such as OAuth – still, its seperate from the identity in this system – more on this later).
  As such, the core point of risk here, is that the user will willingly input his (same) password into several different systems – and now, I (the admin) or any other hacker of my site will have access to Aunt Erma’s passwords for the nuclear missile site.

Hmmm.

Does anything here seem off to you?

It should.

Let’s start with the fact that protecting the nuclear missiles system is not my responsibility, I’m just building a frakkin family outing site (for MY family). So whose responsibility IS it? Umm… How about the nuclear missiles system? Duh.
Second, If I wanted to steal someone’s password (someone who is known to repeatedly use the same password between secure sites, and not-so-secure ones) – why would I bother hacking your site? Or struggling with your symmetric encryption? Goshdarnitall, I can just put up my own simple website, have users sign up to receive VERY IMPORTANT NEWS about whatever they want… Puffo Presto, I “stole” their passwords.

Yes, user education always does come back to bite us in the hienie, doesn’t it?
And there’s nothing you can do about that… Even if you WERE to hash their passwords on your site, and do everything else the TSA can think of, you added protection to their password NOT ONE WHIT, if they’re going to keep promiscuously sticking their passwords into every site they bump into. Don’t EVEN bother trying.

Put another way, You don’t own their passwords, so stop trying to act like you do.

So, my Dear Security Experts, as an old lady used to ask for Wendy’s, “WHERE’s the risk?”

Another few points, in answer to some issues raised above:

• CWE is not a law, or regulation, or even a standard. It is a collection of common weaknesses, i.e. the inverse of “Best Practices”.
• The issue of shared identity is an actual problem, but misunderstood (or misrepresented) by the naysayers here. It is an issue of sharing the identity in and of itself(!), NOT about cracking the passwords on low-value systems. If you’re sharing a password between a low-value and a high-value system, the problem is already there!
• By the by, the previous point would actually point AGAINST using OAuth and the like for both these low-value systems, and the high-value banking systems.
• I know it was just an example, but (sadly) the FBI systems are not really the most secured around. Not quite like your cat’s blog’s servers, but nor do they surpass some of the more secure banks.
• Split knowledge, or dual control, of encryption keys do NOT happen just in the military, in fact PCI-DSS now requires this from basically all merchants, so its not really so far out there anymore (IF the value justifies it).
• To all those who are complaining that questions like these are what makes the developer profession look so bad: it is answers like those, that make the security profession look even worse. Again, business-focused risk analysis is what is required, otherwise you make yourself useless. In addition to being wrong.
• I guess this is why it’s not a good idea to just take a regular developer and drop more security responsibilities on him, without training to think differently, and to look for the correct tradeoffs. No offense, to those of you here, I’m all for it – but more training is in order.

Whew. What a long post…
But to answer your original question, @Shane:

• Explain to the customer the proper way to do things.
• If he still insists, explain some more, insist, argue. Throw a tantrum, if needed.
• Explain the BUSINESS RISK to him. Details are good, figures are better, a live demo is usually best.
• IF HE STILL insists, AND presents valid business reasons – it’s time for you to do a judgement call:
  Is this site low-to-no-value? Is it really a valid business case? Is it good enough for you? Are there no other risks you can consider, that would outweigh valid business reasons? (And of course, is the client NOT a malicious site, but thats duh).
  If so, just go right ahead. It’s not worth the effort, friction, and lost usage (in this hypothetical situation) to put the necessary process in place. Any other decision (again, in this situation) is a bad tradeoff.

So, bottom line, and an actual answer – encrypt it with a simple symmetrical algorithm, protect the encryption key with strong ACLs and preferably DPAPI or the like, document it and have the client (someone senior enough to make that decision) sign off on it.

NOTE: This answer was originally posted at StackOverflow.com by AviD

Sado is a simple PHP ORM package, easy to use, and offers video tutorials

NOTE: This answer was originally posted at StackOverflow.com by Shay Anderson