Are modified implementations of standard cryptographic algorithms better that the standard versions? Since the algorithm is not standard, is it harder to break? Is it safer?
No, modified algorithms they are unlikely to be harder to break, unless the changes were explicitly made by a cryptographer to make the algorithm more secure. They are certainly not any safer just because they are different.
- Due to the Kerckhoff principle you should assume that the algorithm is known. So changes in the algorithm in itself does not increase security;
- If there is a trivial change made then all the attacks on the algorithms are still valid;
- If it is a non-trivial change then the algorithm requires a new security description or proof; basically it should be treated as a new algorithm.
Now in the latter case the algorithm could be safer of course, and many parts of the original security proof may hold. There are many algorithms that have been tweaked to a certain extend to make them more safe or more functional, often by their original authors. As example, for SHA-1 the original, untweaked variant called SHA-0 can be found in the wild.
But to change an algorithm without an explicit idea to fix the previous algorithm is not likely to make it more secure. Most of the time the algorithm will be less secure.
Note that even minor changes in the vectors (internal constants) of symmetric algorithms may completely destroy the security of algorithms. Often these tables were specifically created for the purpose of adding security. If you change one constant in there, you may already break security. Other specific constants may be as safe or even slightly more safe (see for example the changes made by the authors to many of the SHA-3 contestants). In other words, small changes may not equate to trivial changes.
If you change for instance the SHA-2 vectors of SHA-256 to a new, secure set, the you may make it harder to use rainbow tables. But if you use SHA-2 correctly then rainbow tables should not be an issue (because of using salt for password based key derivation). In this way, for very specific attack scenarios, using a modified algorithm may bring some localized benefit. But in general it would be wiser to change the key derivation primitive, of course.
Seems to be opinion-based, since there´s a lack of special point (which modification do you want to make?). But similar questions, that asked for specific modifications, get the same answer: in general, by modifying something without knowing specifically what you´re doing, you´ll be making it worst.
Crypto algorithms are designed with specific things in mind, and changing the smallest detail can have bad consequences. For example, the s-boxes used in DES are specifically designed to make them harder. Other combinations made them more suscetible to attacks.
Increasing the number of iterations on hashes (i.e., applying the same hash 1,000 or 5,000 times) seems to increase the security, but not because the algorithm is weak: by making necessary to compute it thousands of times, the brute-force attack would spend more time, just that.
Despite what I'm writing in the next three paragraphs, you should stick to the advice given by owlstead's answer and never make any even small change to a crypto algorithm (like changing the order of steps), even if you are a competent cryptographer (if you are, you probably wouldn't consider modifications except for very good reasons worth a publication).
There are (hopefully rare) cases where changes of the constants in the official standard improve the security of a cryptographic function.
The best known example is the Dual Elliptic Curve Deterministic Random Bit Generator (Dual_EC_DRBG) that even became an ISO (=international) standard, where the NSA managed to sneak in a backdoor as suspected by Dan Shumow and Niels Ferguson and confirmed by Edward Snowden (for details see the link to the wikipedia).
A second case is the DES where a small change can improve the resistance against linear cryptanalysis considerably (cannot find a reference now). This weakness seems not to be intended and can anyway hardly be used.
Reminder: Anyway stick in your implementation as close to the specification of the standard as possible, and if not possible, get advice on crypto.se.