Question: I am handling a paper as an associate editor that proposed an algorithm that I find to be weak. In fact, I was able to show that a very simple, brute-force approach actually has a better running time than their algorithm. Therefore, I will recommend rejecting this paper. Do I have an obligation to share my proof that the brute-force running time is better? I want the higher-level editors to have confidence in the rejection, but it also occurs to me that I might be able to improve my own result and publish it independently. Is this a violation of ethics?

UPDATE: Well this certainly took off! I would like to add the following:

* The overwhelming consensus is that it would be unethical for me to "scoop" the other authors, so I will not do that. The advice from all is greatly appreciated.
* The journal is the top in its field, so we have to be extremely selective. The problem proposed is fairly interesting, but overall the paper does not meet our threshold.
* When I say that brute force is better than their method, I mean it in a provable, big O sense.
* The authors' proposed scheme is not only inefficient, it is written in a very confusing way. In fact, I asked them to compare their approach to brute-force as a way of helping them clarify their argument, and they did a bad job of it, which is what led me to look into it in the first place.
* The fact that brute force performs better than their scheme is not totally trivial because it relies on a combinatorial argument that is not amazing, but not completely obvious either.
* I will share my proof with the Editor in chief, but I have decided not to give it to the authors; I will consider publishing independently in the future if their work ever appears elsewhere.
* Their paper is not on arXiv or any other website.

Answer: 
Does running time actually matter? 

It's a program for a paper, not something to be distributed and run commercially on many machines. Perhaps they coded it the way they did because that algorithm is more readable and understandable than a brute force approach. 

For example, if something in my paper required me to do something simple like add up the numbers from 1 to n, we all know the sum is equal to n(n+1)/2, but having a loop that goes from 1 to n and adds them together is simpler to read. 

Assuming this is the only 'lousy' thing in the paper that you take issue with, I don't see it as a reason to reject. If you could come up with a brute force approach that quickly, surely they could as well. Perhaps ask them why they chose that algorithm, or ask a senior editor at your paper for a second opinion, not random strangers on the internet.

As far as using the algorithm you wrote yourself goes, the other answers have adequately stated that that would be incredibly unethical.
Assuming that you do not especially care about the topic of the paper that you reviewed, and that the idea that you had while reviewing is not exceptional and did not require huge amounts of work, I think the best course of action is simply to write up concisely that idea as part of your review, and give it away to the authors of the original submission.

If they use it, I agree it's too bad that you won't have credit for it, but you will have gotten other people to polish and write up your idea -- which is probably significantly more effort than what it will take you to concisely describe the idea in the review.

I'd say the main problem is if they don't use it, and you'd like the idea not to die off. I don't know what's a good solution in this case. Wait for their paper to be accepted somewhere, or wait for several years to be sure that they have given up?