Related
Please who can help me recover my safepal wallet from my device... I haven't backed up my mnemonic phrase and I forgot my password now I'm just staring at my money and can't access it .. I have just one more try left... is the anyway I could modify the app data on my phone and change the password or increase the amount of tries left
People can register for a newsletter on my website.
Their email address and other personal information will be encrypted in the database.
Now for that registration form I'd like to check if the newly inputted email address is already in my database, but as all emails are encrypted, I can't really check unless I loop through every possible email address, decrypt it and see if it matches the newly inputted email? Is that correct? Or is there a more efficient way to do this?
If you use the same encryption key all the time, you can simply search for the encrypted version. If you do not, you can still store a hash of the addresses additionally and compare against that.
Just a simple thought: create a table with a md5 hash of the mail and compare this in your SQL WHERE clause? Not sure if this is very effective..
I have a website registration page, and I'm trying to compile a list of what I need to do to protect it. If you know of an attack, please name it, and briefly describe it preferably with a brief description of its solution. All helpful answers/comments receive an up vote.
Here's what I have in mind so far: (and adding what others are suggesting. Phew, adding other input turned out to be lots of work, but please keep them coming, I'll continue adding here)
SQL injections: from user input date. Solution: prepared statements.
[AviD] "Stored Procedures also provide additional benefits (above prepared statements), such as the ability of least privilege on the DB"
Good point, please explain. I thought stored procedures were THE SAME as prepared statements. What I mean those statements were you bindParam the variables. Are they different?
Not hashing the password before entering into db. Solution: hash passwords.
[AviD] "re Hashing, the password needs a salt (random value added to the password before hashing), to prevent Rainbow Table attacks and same-password attacks."
"the salt used should be different for each user."
Good point, I have a question about this: I know salt should be random but also unique. How do we establish the unique part to counter against the same-password attack? I've been reading on this, but didn't get a clear answer on it yet.
[Inshallah] "if you use a long salt, like 16 chars for SHA-256 ($5$) then you don't really need to verify its uniqueness"
[Inshallah] "Actually, I think it doesn't really matter whether or not there are some conflicts. The salt is only for prevention of table lookups, so even a 2 char salt will be a (small) gain, even if there are conflicts. We are not talking about a cryptographic nonce here that absolutely mustn't repeat. But I'm not a cryptanalyst"
Good point, but does anyone have disclaimers on this point?
Dos attacks?! (I'm guessing this applies to registration forms too)
[Pascal Thivent] "Use HTTPs when submitting sensible data like a password." "for man-in-the-middle attacks, provided that adequate cipher suites are used "
What are the "adequate cipher suites" being referred to here?
[Koosha] "Use HTTPs or encrypt passwords before submition with MD5 and Javascript in clientside."
I don't agree to MD5 and don't like encrypting on client-side, makes no sense at all to me. but other input welcome.
[Dan Atkinson] Exclude certain usernames to prevent clashes with existing pages that have the same name (see original post for full answer and explanation)
[Koosha] "limit allowed characters for username.for example alphabet and numbers, dash(-) and dot(.)"
Please explain exactly why?
[Stu42] "Use Captcha so that a bot cannot automatically create multiple accounts"
[AviD] "There are better solutions than captcha, but for a low-value site it can be good enough."
#AviD, please mention an example?
[rasputin] "use e-mail verification"
[Andrew and epochwolf] xss attacks
Although I don't agree with Andrew and epochwolf to simply filter < and > or to convert < to &tl; and > to >. Most opinions suggest a library like HTMLpurifier. Any input on this?
Use HTTPS, i.e. a combination of HTTP and SSL to provide encryption and secure identification of the server when submitting sensitive data like a password. The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted.
Use recaptcha or asirra to avoid automatic submission. That should stop the bots and script kiddies.
To stop hordes of humans from submitting spam (via mechanical turk or anything like that), log each attempt in memcached and as soon as you reach a maximum submissions from the same IP in a given period of time, block that IP for a few minutes (or hours, days, whatever...).
You should use e-mail verification
and addition to Koosha's answer :
if you let usernames including such chars "#&?/" and create user pages like this site.com/user?me&you/ it may be serious problem in browsers. Please think it in url address bar of browsers.
I guess you should use a salt when hashing the passwords.
Use Captcha so that a bot cannot automatically create multiple accounts
If the routes on your website are set in a particular way (ie, going by the username, rather than their id), then having a username like 'admin' could cause problems. You should probably have an exclude list of possible usernames.
This caused problems in the past with MySpace, and people having usernames like login, and then decorating their page with a phishing form.
Edit:
As has been mentioned in the comments by AviD and Peter Boughton, it is also a way of misleading users. Let's say that a user has the username 'admin'. Then, in their user information page (assuming that they each get one that is available to all, like SO), they have some link in their about section that says like
For more information, visit our dev
blog at mysite.cn/loginpage
Someone maybe sees, 'mysite' in the url, but doesn't really look at the TLD, which would be China (sorry China!), rather than the .com TLD your site is hosted on. So they click through, assuming it's alright (they came from the admin user page after all), and this site looks identical to yours but has a login page. So you 're-enter' your details, but nothing happens. Or it redirects you elsewhere.
This is often the tactic of bank scammers who wish to target customers, inviting them to go to their website to 're-enter a banking password'.
This is just one more form of a type of security known as 'Social Engineering'.
Filter user's data removing '<', '>' - simply html tags. If someone can view user's profile there are possible XSS attacks through data.
Use HTTPS
Use Captcha.
Limit allowed characters for username in server side. for example alphabet and numbers, dash(-) and dot(.).
PS. Clientside encryption is not a secure way. but if you can't use HTTPs, clientside encryption is better than nothing.
Limiting characters, Its a simple way to protect your software from injections(SQL/XSS).
Suppose you've got a webapp that's passing usernames and passwords around in hidden form fields.
I know it's a very bad idea, but I'm interested in enumerating why... any thoughts?
update - This is a hypothetical question.
I couldn't find a resource that just enumerated the reasons - I know of plenty of reasons why it's a bad idea, I'm looking to see if there are any other reasons I haven't thought of and create that resource I was looking for. Thanks!
A number of reasons why it is a poor idea:
1) As pointed out, if you view source, inspect element, or anything similar, then the username/password is easily discovered.
2) Unless your transport layer is encrypted, they will be easily intercepted.
3) If the browser caches your html page, then that file with a username/password is now stored on that person's computer.
4) If that user saves the page to give to someone else, then their username/password goes with that page.
5) A POST method accidentally gets changed to a GET, now the password and username is stored in the server access logs....
Etc, etc.
There is no real reason to do it in my opinion, especially when you can use session cookies on the server, or some other method that doesn't expose private information to the client.
Edit: Come to think of it, I have done this once before. I put a password in a hidden field, however before doing so I encrypted it with a secret key known only to the server before printing it out, and then when I got the password posted back to the server, I decrypted it. Therefore the plaintext password is never with the client.
Edit 2: Should probably point out that the method described in the previous edit was not used for directly authenticating someone, as per hobbs point.
It's so easy for anyone with access to the current page ( might not necessarily be the same person who log into your application) to view the html source and get the user name and password.
If I log into my gmail, and leave my desk, and you come in and you can see all my email messages. But no matter what you can't see my gmail password. But if gmail passes the password around in hidden field format, then you can see my gmail password.
The page could get cached in a user's browser.
The page could get cached in a proxy server.
Worst of all, the page could get cached by a search engine.
In all cases the content containing username and password might be served to a person who is not supposed to see it.
I don't think storing a username in plaintext is so bad, and in some cases it might be beneficial to do so.
Storing passwords, however, are a different story. It would be very easy for someone to packet sniff your data going across the network (there are many points on its journey that this could happen) and logon using your credentials.
A golden rule I follow is never store a plaintext password anywhere, ever.
I think the biggest risk here is that any XSS vulnerability now allows password stealing. XSS is much worse than it seems. There isn't really any excuse for XSS vulnerabilities, but people make decisions such that they become rather inevitable.
Perhaps the second biggest risk is caching. These passwords are going to end up on disk and be available to any malicious code trawling through files. Having said that, most passwords can end up on disk through swapping and hibernation - it becomes a matter of probabilities.
Typically when I need an official resource for listing possible attacks or weaknesses, I turn to:
Common Weakness Enumeration
http://cwe.mitre.org/
Common Attack Pattern Enumeration and Classification
http://capec.mitre.org/
Taxonomy of Software Security Errors
http://www.fortify.com/vulncat/
Amazingly, storing username/password in a hidden form field is such an egregious error that it hits about 20 issues within the CWE.
Just to get you started:
http://cwe.mitre.org/data/definitions/352.html
http://cwe.mitre.org/data/slices/384.html
http://cwe.mitre.org/data/definitions/471.html
http://cwe.mitre.org/data/definitions/472.html
http://cwe.mitre.org/data/definitions/639.html
http://cwe.mitre.org/data/definitions/642.html
http://cwe.mitre.org/data/definitions/656.html
Well, the dangers vary depending on what you mean by "usernames and passwords".
If you're referring to the usernames and passwords being validated against, I invite you to choose View->Source in your web browser. This is no security at all.
If you mean the username and password of the user logging in being placed in a hidden field before being sent, there's absolutely no difference between that and your standard text and password fields. The only security risk here are passwords being sent in-the-clear without a TLS/SSL connection to encrypt it, allowing for packet sniffing to see the credentials.
Wiretapping, especially if the transport layer is not encrypted
unless all your pages are served over https it's bad because usernames and password are sent in clear text over the network constantly and can sniffed.
Even if all pages are served over https it's bad because if a user forgets to close his/her browser, anyone with access to the computer can view the source and read the password.
It gives the users a false sense of security and I would recommend that you change it if at all possible.
i'd like to prevent bots from hacking weak password-protected accounts. (e.g. this happend to ebay and other big sites)
So i'll set a (mem-) cached value with the ip, amount of tries and timestamp of last try (memcache-fall-out).
But what about bots trying to open any account with just one password. For example, the bot tries all 500.000 Useraccounts with the password "password123". Maybe 10 will open.
So my attempt was to just cache the ip with tries and set max-tries to ~50. The i would delete it after a successful login. So the good-bot would just login with a valid account every 49 tries to reset the lock.
Is there any way to do it right?
What do big platforms do about this?
What can i do to prevent idiots from blocking all users on a proxy with retrying 50 times?
If there is no best practice - does this mean any platform is brute-forceable? At least with a hint on when counters are resetted?
I think you can mix your solution with captchas:
Count the number of tries per IP
In case there are too many tries from a given IP address within a given time, add a captcha to your login form.
Some sites give you maybe two or three tries before they start making you enter a captcha along with your username/password. The captcha goes away once you successfully log in.
There was a relatively good article on Coding Horror a few days ago.
While the code is focused on Django there is some really good discussion on the best practice methods on Simon Willison’s blog. He uses memcached to track IPs and login failures.
You could use a password strength checker when a user sets their password to make sure they're not using an easily brute-forced password.
EDIT: Just to be clear, this shouldn't be seen as a complete solution to the problem you're trying to solve, but it should be considered in conjunction with some of the other answers.
You're never going to be able to prevent a group of bots from trying this from lots of different IP addresses.
From the same IP address: I would say if you see an example of "suspicious" behavior (invalid username, or several valid accounts with incorrect login attempts), just block the login for a few seconds. If it's a legitimate user, they won't mind waiting a few seconds. If it's a bot this will slow them down to the point of being impractical. If you continue to see the behavior from the IP address, just block them -- but leave an out-of-band door for legitimate users (call phone #x, or email this address).
PLEASE NOTE: IP addresses can be shared among THOUSANDS or even MILLIONS of users!!! For example, most/all AOL users appear as a very small set of IP addresses due to AOL's network architecture. Most ISPs map their large user bases to a small set of public IP addresses.
You cannot assume that an IP address belongs to only a single user.
You cannot assume that a single user will be using only a single IP address.
Check the following question discussing best practices against distibuted brute force and dictionary attacks:
What is the best Distributed Brute Force countermeasure?