Doing a little bit of research on security and it strikes me how very insecure many of the browsers are. For example passwords are stored in plaintext if 'Remember Password' is selected on a website login, and are easily revealed if the machine is unlocked or insecure.
I was wondering for example once the session has been logged in, where is the password stored then? I realize if the connection has SSL/TLS enabled any content to and from the server is encrypted, but what about at the local computer. Is the password still kept in plaintext somewhere within the browser or does it immediately become encrypted when you login?
Websites are not that unsafe. You are confused because you are mixing 2 different things:
Your browser can save passwords of website you log in if you ask it to do so.
Here is. for instance, how you can enable this feature on Firefox by checking Remember passwords for sites option:
If you are worried about the security issues of your passwords you use to log into your favorite websites (you should), then you can use a password manager which stores your passwords encrypted on your machine.
What I mentioned above is not to mix, and has nothing to do, with the autoLogin (Remember Me) feature which could, however, have security failures depending on how it is implemented (mainly if your website's developers are enough bad to code cookies that contain your credentials).
Edit: As long as the website doesn't explicit tell the browser to save it in the cookies, it is not saved anywhere, because the browser only sends cookies to the server once you logged in. (Yes, i know there's also background information like agent etc., but that's not the topic here!)
Another exception would be a webpage that is using $_SESSION Cookies - then the browser must send it in every new session of course! But that's a completly new LogIn-Session with new Cookies every time.
OLD:
Are you talking about where you can find the password like
about:preferences#security in Firefox, where it is possible to show the password in completly plain text, or the actual physical location on the drive?
sorry for posting question in answer btw - I was not allowed to comment your question :/
Related
I recently logged into a website (student run club website which stores event and participant information).
After successfully logging in the following message appears and follows me around for the rest of my time on the site:
You are using an insecure password. The password that you entered has
been exposed in at least one data breach.
How do you know my password is insecure? This password appears in a
database of known passwords. Hackers may use this password to try to
break into your accounts.
While I appreciate the notification that my password was compromised (and should know better and will change and stop reusing passwords etc etc) I now worry about the overall security of this site.
I don't know a terrible lot about web dev but my naive assumption, given this message and the fact that it appears after log in, is that my password must have been stored in plain text for them to be able to check it against a database. Is this correct? Or is there some clever secure way this could be done?
Just because you are receiving a notification from the site doesn't mean that your passwords are being stored in plaintext. Whatever website you are using can use your password in the "Have I Been Pwned" API before encrypting them. This of course doesn't necessarily mean that they are encrypting them as there isn't really a surefire way to know how they are storing your passwords without possibly contacting the owner or if you were to receive an email at a later date with your password in it.
You can read up on the API for password checking here haveibeenpwned.com/API or you can check for the website you are using in this list here haveibeenpwned.com/API/Consumers.
People need to log in to start using my app. They can register themselves on my website and their passwords are stored using Bcrypt. When they login in the app I transfer the password as plain text in a GET request (https://website.com/file.php?pass=password) to a php file which is using Bcrypt again to compare the password to the one stored in my database. My website uses a SSL certificate and with that a HTTPS connection at all times. So my NSURL starts with a HTTPS request. My question is, is it safe enough this way or is it completely unsafe? If so what would you suggest to validate the login of the user?
I think that using HTTPS is a great start. As zaph points out, you might want to check to make sure that your server is using TLS 1.2.
I agree with SLaks, though, and advise against GET request. Section 9.4 of RFC 7231 warns "Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead."
As you're thinking about NSURLSession security, I'd suggest that you make sure that you do not do any caching during user authentication, perhaps even using an ephemeral session, so that this data that you've gone to such lengths to encrypt isn't unintentionally stored elsewhere unencrypted.
I might also suggest watching WWDC 2015 videos Security and Your Apps, Privacy and Your App, and Networking with NSURLSession. These don't tackle your question directly, but they do touch on some some broader security/privacy issues.
HTTPS is safe if the server is using TLS 1.2 and perfect forward secrecy. Also if the server is using 2-factor authentication and the second factor is well controlled.
But you also need to pin the certificate in your app to prevent MITM attacks.
What is the simplest way to make a page accessible by username/password? In school I learned to do this on the server side using sql and java. I'm wondering is there a way to do this only on the client side?
EDIT: lol... based on the responses, I probably should say why I specified client-side. I'm being asked to load an extra page into our company website that is supposed to aid some of our employees. I didn't design this extra page, and I was asked to put this up with a very simple log in. Granted I need to confirm with my superior that a client side login is ENOUGH, I just wanted to know if it could be done IF they decide that it's not all that important. The page itself won't have a link on the site, so unless someone knows it's there or decides to snoop, nobody will even know it's there.
You can save your page into a directory protected by .htaccess file.
That would be server side (you have to upload a .htaccess file into the directory).
But client side? Hmmmm the only thing I imagine is to create a DIV with position: fixed that would be over all your page content.
Ask for a user and a password, then check them using Javascript (this is client side), then you add property "display: none" to the DIV that is containing the login view.
That would hide the login view and show the page that is below it.
This is a HUGE security problem in my opinion. I could easily edit your web with Firebug and add Display: none to the div without entering a password.
However, as the password IS in the Javascript I could look at it anyway just viewing the source code.
The easiest is probably server side apache authentication. Use these two generators for that:
http://www.htaccesstools.com/htaccess-authentication/
http://www.htaccesstools.com/htpasswd-generator/
Just on the client side, using javascript it's never secure enough. But there is way:
if( prompt('Enter password') == 'password' )
{
// we are okay
}
else
{
// password is wrong
}
For more robust example, with username see http://jsfiddle.net/7mZYQ/2/
Well you could try a basic JavaScript dummy with HTML inputs that would somehow offer the slight illusion of password protection. Otherwise, create an HTML form and go with PHP Sessions. These are probably the languages with the most tutorials around so it wouldn't take you that long to pull it off.
You cannot do this securely only on the client side, it would require you to perform authentication of the user inside the browser. This means your whole userbase would have to be loaded in the browser memory in some form, likely in javascript which makes it unsafe.
For a simple authentication mechanism which involves the server to a minimal extent look at Basic Authentication.
No, it cannot be done on the client side. At least not in a secure manner. Client side (password ) validation is very easy to bypass, because clues (such as the password and/or the content you want to show when the correct password is entered) are given to the user.
If you think about what "client-side" means, you'll understand why it wouldn't be possible. On the client side, all information is processed and all data is stored on the client's machine. Thus, in order to check passwords totally on the client side, you'd have to have the entire list of usernames passwords saved to every single computer that your site interacts with.
Keep in mind, also, that anything "client side" is inherently less secure than it would be server-side. So even if you could do this, it'd probably be a bad idea.
Now, that being said, here's how you could do it:
Come up with a password (note that you'll have to use a master password, not individual ones), hash the password, and store the hashed password in a variable, or something. It may sound insecure, but if you're hashing the pw, you could send everyone a personalized email with the password and it wouldn't make it any easier to hack. Hashing is a one-way operation. There is no way to reverse engineer it. Do make sure to make your stored password a constant, though, or someone could just change the value of their hashed password last minute to match your stored one. Give the css rule Display:none; to your data with css so that it hides. Now prompt the user for a password. Then, take that password and run it through the same encryption as you did when you created the password. If that value and the one you stored match, bingo. Just revert your display:none; and you're good to go.
Though I guess that still leaves the problem of somebody just firebugging your display:none away. Guess you'd have to encrypt the data on the page too.
Recently I had problems with my email account (gmx.net). I have about 30 failed login attempts a day. But that is not the topic of the question (I already changed my password).
It got me thinking. Is this in automatic attack? And if so, how is it done? I took a look at the HTML code of the page and found out, that it is pretty easy to just copy the source code of the form element and do a login attempt through a local html file (copy and paste, new HTML file, open in browser, enter your credentials, submit). That means it is an easy task to automate such things (write a little script, that does a post with various values --> Brute Force attack). I was about to write an email to the mail hosted, when I found out, that the exact same process can be done on facebook.com....
I had the impression, that since we have all these new fancy web frameworks like Rails, Django and so on, we have an automatic protection against such attacks (for example the protect from forgery which Rails includes http://ruby.about.com/od/security/a/forgeryprotect.htm)
My question here is:
Is there any sane reason to allow a login attempt from another server?
Don't give me "API", the most APIs for web application require a manual login process before authorization.
I know there are many more ways to brute force attack any website login (use a framework that controls a browser etc...) and there are many ways to protect (IP-banning etc). But shouldn't disabling a remote login be one of the first security mechanisms you would take?
My website has been compromised. Some one have injected some iframe markup in my website.
How they have done this? Only on my index.html, index.php page. But I have blocked write permissions for this page, then how they able to write in my pages.
Will it effect other pages on my server?
Is there any other solutions to block this?
Thank you
<?php`
include_once("commonfiles/user_functions.php");
include_once("user_redirect.php");
include_once("designs/index.html");
?>
<iframe src='url' width='1' height='1' style='visibility: hidden;'></iframe>
This is my index.php code <iframe> is injected after the php script.
Someone with FTP access to your site (you or your developers) has a virus on their workstations. This virus has installed a keylogger that is stealing credentials from your FTP client and sending this information back to the hacker.
The hacker collects hundreds of such credentials and then uses a program to log into each server, download a file, modify it to append an iframe or block of obfuscated JavaScript or PHP, upload the file, download the next file, modify, upload, next, etc. The files downloaded may either match a set of names (such as only index., default., home.* etc) or just any html or PHP file.
The appended code is often either an iframe that is visibility: hidden or of 1x1px size, a <script> sourcing a remote JavaScript file on a dubious domain, a collection of Javascript obfuscated by some clever str.CharCode'ing, or a block of base64_encode'd eval()'d code. Unobfuscating the code, the result is often an iframe. More recently, some clever attackers are inserting remote shells, granting them backdoor access to your server.
Once all the files have been modified, the attacker logs out. Visitors to your site will be subject to malicious code from the domain linked in the iframe with the intention of installing viruses and rootkits. Among other functions, these viruses will install a keylogger to sniff FTP credentials... and the virus continues spreading.
The attacker is using your credentials, so they can only access files that you have access to. Sometimes, they will upload an additional file in certain directories with an encoded shell, allowing them return access to the server (the common ones are _captcha.php in /forums directores and img.php or gifimg.php in /gallery directories). If you host other domains on your server, as long as the user for the affected domain has no access beyond their current domain, others will not be affected.
There are two ways to stop this sort of attack -- prevention and proper antivirus. The attacks can be easily deflected by use of a firewall and limiting FTP access to only a few select IPs. The attackers are not attacking from your own workstation (yet), but rather a server elsewhere in the world. Using proper antivirus on all workstations with access to your FTP account -- or, better yet, not using Windows XP -- will help prevent the original infection from occurring.
If you are infected, it's fairly easy to clean the messes up using a bit of clever sed, depending how good you are at spotting the injection and making effective regexes. Otherwise, backups backups backups -- always have backups! ...Oh, and change your FTP password or they'll be back tomorrow.
If the php file itself has been edited to include this iframe and if there truly is no way for another script you are running to write to the file then a user account with access to the file might have been compromised. If there is a user account with access to the file that has a weak password this would be my candidate as the most likely culprit.
They may have used some form of injection on your site to acquire usernames and password hashes and bruteforced those, they might have installed a keylogger on someone's machine who has access, or they may have just brute forced your login directly (assuming you don't have some sort of mechanism in place to prevent this).
First thing I would do is ensure there are no viruses running on anyone's computer who has access to the machine. Then go about changing passwords. And finally review the php scripts of the site for possible points of injection. Trouble spots are pretty much anywhere you're taking in some kind of user input and processing it without first checking to make sure it is safe to process (i.e. failure to strip dangerous characters from a user login form).
From the comments that have been posted so far it seems almost certain that someone has gained access to a user account with write permissions on the files that are having code injected into them. It sounds like some individual has discovered one or more account passwords and has made it their pastime to occasionally log into your FTP and make some changes. Have you tried changing your passwords? I recommend using a fairly secure password, of at least 15 characters and using a variety of character types including unprintable characters if you are able (use alt/meta keys to enter UTF codepoints on the number pad).
If, after changing your password, you still observe the same problems, then there could be another issue. I would first seriously scrutinize your PHP scripts. Anywhere your scripts accept user input from a form, data stored in a cookie, or other data originating from outside the script itself (and therefore potentially "dirty" data), go over the operations of the script with this data very carefully. If you are using any such potentially dirty data to run an OS command, open/read/write a file, or query a database, then it is possible that the data contain escape characters that will escape your code, allowing an attacker to execute any code they wish within your script.
Keep an eye on your access logs. You mentioned that you remove the injected iframe code from your scripts and it keeps being re-injected, so if you can catch when it happens you can probably find a clue as to the source of the changes in your access logs.
See this thread for more on trying to block iframes.