Password encryption scheme
About using plaintext passwords, see the other answers. It's not a good choice. BCrypt (readily available with PHP) is the way to go.
To be really paranoid you should make it so that, if the user is not in the database, a fake user is recovered with a surely wrong password (e.g. the password supplied by the browser user, plus one letter). Then run the password check all the same. This will prevent timing attacks designed to fish out what users are in the system (longer check time) and what users are not (fast, immediate fail), by forcing the longer check time for all user regardless of whether they exist or not.
Exploitability
In general, accepting user input without checking/escaping must be considered always insecure.
In your case of course the 1=1 exploit does not work, and the semicolon exploit is harmless against MySQLi.
But what about an injection against User, and supply this in the POST:
username=foo' limit 0 UNION select 'pwn3d!' AS Pass;--
password=pwn3d!
Now the query becomes:
SELECT Pass from login WHERE User='foo' limit 0 UNION select 'pwn3d!' AS Pass;--';
or if one wanted to avoid -- and ; on the ground that some SQL analysis might reject the query as unsound (e.g. because it's a multiple query, which is uncommon or unsupported, and anyway suspicious), this more complicated username
foo' LIMIT 0 UNION SELECT 'pwn3d!' AS Pass UNION SELECT Pass FROM login WHERE ''!='
which will yield:
+--------+
| Pass |
+--------+
| pwn3d! |
+--------+
1 row in set (0.00 sec)
And of course since we chose the password, this is always equal to the password we supplied.
So the login check will pass.
This is the fiddle (removing SQL comments, which SQLfiddle seemed not to like).
This requires the attacker to know the name of the password field, and in a real world implementation this attack, implemented as above, will not work (the user information is lost). But depending on the real implementation, it is possible to tweak it and actually get logged in as any user, provided you know his/her login name, without even knowing what the password is.
Another interesting possibility would be to store the MD5 hash of the username together with the username. Then the query could be
SELECT * FROM (
SELECT * FROM login WHERE hashed_username=?
UNION
SELECT [list of default fields], ? AS Pass
) LIMIT 1;
which always returns exactly one record whether the user is there or not; the supplied value for hashed_username is md5($_REQUEST['username']) which would prevent any SQL attacks even if we weren't using prepared queries, and with an index on hashed_username guarantees that timing attacks are unfeasible. The supplied value for the default password is BCrypt::hash("_NOT_".$_REQUEST['password']).
At this point we just run BCrypt::verify($record['Pass'], $_REQUEST['password']) and see whether it returns true (user exists, password OK) or false (bad user or bad password). The two execution paths are now close enough that no reasonable amount of bruteforcing can lead an attacker to uncover either a valid username or a password. A suitable BCrypt round value also guarantees that bruteforcing a compromised database isn't really feasible.
At this point the vulnerable spot is password strength. Remember that a password policy so complex that users find practical or necessary to write it down and tape it to the monitor is actually detrimental to security (been there, done that. Sigh).
