hi i used this simple form which are these..but i want to protect password from oracle database if user enter wrong name and password then not login otherwise login

 <!DOCTYPE HTML> <html> <head><br> <style>
.error {color: #FF0000;}
</style> </head> <body style="font-family: verdana, sans-serif;";> <hr /> <div style="width: 77%; height: 300px; padding: 30px; border: 5px solid #e3e3e3; background-color: #F8F8F8 ; color: #000; margin: 100px;" align="center"> <br> <h2>Login</h2> <form method="post" action="login.php"> <font size="3">name:<input type="text" name="name" style="padding: 4px;"/><p>
      password: <input type="password" name="password" style="padding: 4px;"/><p> <input type="submit" value="Login" style="padding: 4px; width: 5em; height: 1.9em;"/></font> </form> </div> </body> </html> 

Dani AI

Generated

Short answer for : stop storing or trying to “encrypt” plaintext passwords. Use one‑way, adaptive password hashing on the server and verify the hash on login. In PHP that means using the built‑in helpers: create a salted adaptive hash with password_hash() and check logins with password_verify(); modern guidance (Argon2id or bcrypt) and per‑user salts are what you want. (php.net)

Practical flow (registration vs login) — keep it simple and server‑side:

# registration: hash then store
$hash = password_hash($_POST['password'], PASSWORD_DEFAULT);
// store $hash in your users table

# login: fetch stored hash, then verify
$stored = /* fetch hash for submitted username using a bound query */;
if ($stored && password_verify($_POST['password'], $stored)) {
    // success: create server session
} else {
    // failure: generic error, throttle / count failed attempts
}

password_verify() is designed to verify safely (timing‑attack resistant); use password_needs_rehash() to upgrade hashes when you change the algorithm or cost. (php.net)

When talking to Oracle: never build SQL by concatenating user input. Use OCI8 binding or parameterized queries (for example oci_parse() + oci_bind_by_name()), so user strings are data, not SQL. Protect the auth endpoints from user‑enumeration (always return a generic “invalid username or password” message and keep timing similar) and add throttling/lockout/CAPTCHA or MFA to slow brute‑force/credential‑stuffing attacks. (php.net)

Also serve the page over TLS, monitor failed attempts, and do not roll your own crypto — rely on well‑tested functions and the OWASP guidance for password storage and transport. Those measures together (hash, bound queries, TLS, throttling/MFA) are the minimal, practical way to “protect passwords” for a PHP + Oracle login flow. (devguide.owasp.org)

Is this similar to https://www.daniweb.com/programming/threads/511883/display-name

Remember you need to not only show the other code in the backend but do not discount this has been done so many times both right and wrong. Again, never store the password in the database. You encrpyt (see how on the link I noted before) then compare the encrypted version from your login with the encrypted version in the database.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.