Is it possible to have two SSL certs - one wildcard and the other single sub-domain for a single domain? We have a case where we are currently using *.yourdomain.com (wildcard certificate) and due to some reason we need another certificate (Multi-domain UCC certificate) for subdomain.yourdomain.com.

On a few of our systems the *.yourdomain.com will remain active whereas on the rest of our systems we'll be using the new UCC certificate subdomain.yourdomain.com.

Can two of these certs co-exist for a single domain and not cause clash?

Regards,
Uzair

Can two of these certs co-exist for a single domain and not cause clash?

As long as both certificates are valid and match the hostname it should be no problem from the client side.


Is a self-signed SSL certificate much better than nothing? I have a server which hosts my own internal code among other things. Since it's only me using it, I've generated a self-signed SSL certificate and key, hoping that it'd give me a bit more security than just HTTP.

I would think that the main advantage of having a signed certificate is that someone else authenticates and verifies the certificate, ie: Verisign says that sitea.com is legitimate and certifies it. However, since I'm not so concerned about the entire world knowing that my site is valid, does a self-signed certificate still give me much better security than just raw HTTP?

If this is insecure, would a verified  client-side certificate installed on my computers greatly enhance the security? I want this to be secure  and if possible to not have to shell out a bunch of money per year for a site which only I by myself will be using.

Self-signed certificate means that:

You are still using SSL, so you use encryption, so you are defeating passive attackers: someone who wants to see your secrets will have to commit visibly to the effort, by mounting a fake server or a man in the middle attack.
On the client side, you can use "direct trust", i.e. specifically instructing your browser to trust the specific server's certificate. The first connection to the server is vulnerable to a MitM, but afterwards you are protected. See this answer for some discussion.

So yes, in many situations, SSL with a self-signed certificate is much better than no SSL at all. Of course, "better" and "good" are not the same thing...

A client-side certificate is about convincing the server of the client identity. A fake server is able to ask for a client certificate just like the genuine server, so no improvement here. A client-side certificate can help against MitM, though, if the genuine server is educated to require a valid client certificate (a true MitM is a double-impersonation: the genuine server talks to a fake client, and the genuine client talks to a fake server; if the server requires a client certificate, then half of the MitM won't work, namely the part with the fake client).


Reusing passwords that can possibly never be cracked Reusing passwords pose as a terrible risk for users because in the event of a data breach, with the passwords not being stored securely enough, this means that, by default, all other services that they use this password for are also compromised. Typically with these breaches they store the password using only a hashing algorithm like SHA-1, or even still MD5 in some cases recently (which were never meant for storing passwords securely), making it easy for attackers to bruteforce passwords using just raw GPU hash power.

If a person was to create a properly random password of sufficient length (e.g. 100+) of very sufficient entropy which is mixed with many types of symbols, numbers and letters; in the case that their machine is not compromised in the sense that there is a keylogger installed or the like, and all their browsing sessions are done through an encrypted tunnel, is there a risk in reusing this password for multiple websites if it can possibly never be cracked in their lifetime if a data breach occurred on one of the services they use?

You don't need to bruteforce a hash to steal a password. A website might be compromised by an attacker so that they can read the passwords directly from the login form, in plain text. Or the website owner might be doing this, they could always do it if they wanted to, it's up to you whether you trust the owner or not (you wouldn't want to use the same password on Facebook and SomeBlackHatCommunity dot com). Also, there is always the good old shoulder surfing for stealing passwords. A password is like a key, and by using the same password you are actually giving the same key to different doors to different people. You can see it's never a good idea.

So you should never use the same password in different places, unless that password protects the same data or gives you the same privileges, so for example I believe you can use the same password to protect your backups.


Dealing with excessive "Carding" attempts We are currently setup using Magento on a LAMP stack for our e-commerce platform. As of a month or two ago we began noticing a lot of carding attempts against our website. All attempted transactions would be for a small amount, just to check if their credit card is valid. As one is declined they usually try it again repeatedly changing the card number by 1 or 2 numbers. These attempts happen very quickly, in succession. As you can imagine, this adds up quickly in our credit card processors system and often times we get shut down for a brief period of time to prevent more attempts.

Most of the attacks were coming from outside of the U.S. and we are a U.S. only business so we used mod_geoip to deny all traffic from outside of the country. This has helped with the mass attacks but we still get people carding from U.S. origins. I am really interested in knowing what’s going on here. How do they setup scripts to mass attempts orders like this? Is there really anything else I can do to stomp this out? Any insight on these types of attacks is appreciated!

  This question was IT Security Question of the Week.
  Read the Sept 14, 2012 blog entry for more details or submit your own Question of the Week.

Given that you have strong verification of name / address, etc., it's most likely that your site is known to return different values for different types of errors. The best thing you can do to discourage card testing is to ensure that any declined transactions provide the same result regardless of the reason that the processor told you it was declined.


Are any inherently insecure AES-CBC keys or key-IV combos known for properly generated random values? This is mostly a theoretical question.

I am using AES128 CBC to encrypt small files.  Both my keys and my IVs are randomly generated per file using iOS's secure random value generation (SecRandomCopyBytes).

1) In theory, do I need to check for any inherently insecure Keys, IVs, or key-IV combos (ex. although completely unlikely, if the Key and IV both end up being all zeroes, is it just as secure presuming an attacker does not know this)?

2) Can I rely on Apples random value generator for this?

A CSPRNG is expected to return every possible value of the image space with a probability indistinguishable from a random distribution.

Leaving certain results out would make a bad design. Think of dice. If you roll 1-1-1, you would not think that this is not random enough and sort it out - You just generated that entropy with certainty that it is real.

Doing so with an PRNG would compromise it's security, so no, there is nothing filtered out, hopefully.

Side note here: even if the probability is very small (so small as to be negligible): you are not supposed to reuse the same IV on the same key with AES-CBC, as to not leak anything if your files share structural information

Other than that, you should be fine with your approach. Every call to SecRandomCopyBytes you may consider a dice roll, for all you care about, as it's the best entropy you are going to get.

If your aim is not only confidentiality but also data integrity, you would be better off using another mode of operation as pointed out in the comments. I know, iOS is not very generous in giving much choice there, though.


Overarching term for 'authentication' and 'authorization'? The internet is rife with 'authentication vs. authorization'-type questions. I'm not asking that here. I'm wondering if there is some overarching term that encompasses both of these.

I've seen authentication referred to as 'identity management', and authorization referred to as 'access control'.

But even AWS didn't have a good term for both of these together, so it created IAM.

So again, if authentication is proving who (as a principal) you are, and authorization is about giving that authenticated principal access levels, then I'm looking for an umbrella security term that applies to both (hence, governing who can do what for a particular resource). Does this exist?!

According to CISSP study guide , access control include IAAA (Identification, Authentication, Authorization and Accountability).

So if you dont care about the rest then you can call Authentication and Authorization  as Access control.

Where:

Identification : User_Name

Authentication : User_Name + Password ( in one factor auth , simple case)

Authorization : Access to resources once authenticated

Accounting :  Tracking who did what


For security reasons, can I block ping response on my router without disabling my network? I seem to have a serious problem of being attacked and after looking up the attack source, 99% come from China, then Korea, Hong Kong etc.  Here is a fraction of the report from my Router, which is a Cisco WRVS4400N router.

1   2014-01-06 14:53:32 CHAT GoogleTalk login attempt -2    173.194.73.125
2   2014-01-06 14:52:44 Possible DoS HGOD SynKiller Flooding    59.53.68.179
3   2014-01-06 14:45:17 CHAT GoogleTalk login attempt -2    74.125.137.125
4   2014-01-06 14:37:02 CHAT GoogleTalk login attempt -2    74.125.139.125
5   2014-01-06 14:36:31 Possible DoS HGOD SynKiller Flooding    202.109.143.95
6   2014-01-06 14:36:31 Possible DoS HGOD SynKiller Flooding    202.109.143.95
7   2014-01-06 13:49:46 CHAT QQ&TM Login attempt via TCP -1 74.125.134.138
8   2014-01-06 13:48:29 Possible DoS HGOD SynKiller Flooding    61.147.113.83
9   2014-01-06 13:09:48 Possible DoS HGOD SynKiller Flooding    184.164.71.144
10  2014-01-06 12:55:32 OVER_PING_LENGTH    192.168.17.100
11  2014-01-06 12:55:32 OVER_PING_LENGTH    192.168.17.100
12  2014-01-06 12:55:31 OVER_PING_LENGTH    192.168.17.100
13  2014-01-06 12:55:31 OVER_PING_LENGTH    192.168.17.100
14  2014-01-06 12:55:30 OVER_PING_LENGTH    192.168.17.100
15  2014-01-06 12:55:30 OVER_PING_LENGTH    192.168.17.100
16  2014-01-06 12:55:29 OVER_PING_LENGTH    192.168.17.100

And this is the graphic of when the attacks take place and how much data is transferred from my PC out there

Can anyone help me understand if blocking the ping response can alleviate this problem.  It appears to me that they are breaking through everything I have set up in the router to prevent these hackers from accessing my PCs.

Or if anyone has alternative advice, it is welcome.

DK

Even if you could, disabling ping requests would do nothing... for real, it's just for testing purposes.

Apparently you're being somehow DDose'd... i would suggest reading here.

The only 100% effective recommendation is for you (if you don't have a static IP) reset your router and check if the IP changed, (it should if you have a dynamic IP.) if yes, you're safe, unless the attackers have other ways to get your IP... if it didn't change, or you have a static IP, you should call your ISP and request them to change your IP address because you're being DDose'd.

Edit: In answer to your comment on @Ajaxasaur answer (i can't comment :/) you could install a firewall on your computer like COMODO firewall (i believe it's free) and check all connections made from your computer, inbound and outbound.


Is it possible to provide malware from a router? I received a disturbing mail containing the password for my desktop computer account. In this mail the hacker stated that he used a vulnerability in my router with CVE: CVE-2020-1672.
After searching for this CVE I found https://www.cvedetails.com and https://cve.mitre.org, but I did not find this specific CVE code. Can anybody provide material to read about it? Or is it common that ransomware hackers will tell you "ha, I hacked you that way" and in reality me or my wife just went to a malicious webpage?

The hacker states, that he made backups of my data, also containing personal data, and used the webcam to take some screenshots. He will encrypt all my data and send compromising material to my contact list.

I am using EA2700 Linksys as my W-LAN router and Fritz!Box 7412 for connecting to the internet. All my devices are either Android based or use Windows 10 as OS.

Is it possible to provide malware from a router? Would the hacker need to change DNS for that? I checked this but there only standard DNS Gateways configured. Might the hack have taken place more than a year ago? This was when we moved and I started using the Fritz!Box due to a new provider and also reset the linksys device.

I am using Bitdefender Internet Security 2019 on most of the devices that has been connected to the router. It states that it has a ransomware security tool which will prevent ransomware from encrypting my data. Has anybody an idea how that really works? Is this something I can rely on?

A colleague whom I told about the hack told me to check out dd-wrt. Can flashing my router with this (custom?) firmware realy increase my security?

Sorry for asking that much but I am a little bit worried.

That CVE number is totally bogus. The format for CVE's is CVE-[YEAR]-[number], so any CVE issues this year would start with CVE-2019, CVE-2020 won't be around until next year. The fact that you couldn't find the number on Mitre's website confirms that.

Mails like the one you received are scams. They try to make some quick money by threatening to disclose private information. To scare you off a bit, leaked password dumps from websites are used to "prove" that they have information on you. I've seen dozens of them sent to my various personal addresses in the last couple of months. Since I use a unique emailaddress for every website I need to create an account on, it's often easy to trace the mail back to a specific site, which almost always has had a password leak.

Personally, I wouldn't be worried about such threads.

To finally answer your original question: it could be possible, but there are many easier ways to gain access to someones computer and files, mostly through outdated software and tricking people to install something they shouldn't.


is it illegal to share customer credit card data I have an app where users can enter credit card data and it is stored using a 3rd party toservice like BluePay or Authorize.net, I do not and will not save it in  my system.  Trying to get this point across to potential new customers is sometimes hard to do.

I want to tell them that it is actually illegal to collect and then share credit card information, but is this actually a true statement?

I wouldn't take that approach, because it is an inaccurate statement: it's not a 'legal' issue per se, it's a Payment Card regulations issue. I would simply say that credit card information falls under PCI DSS regulations which prevents companies from storing the card information at all unless they use a compliant system. To comply with regulations with storing and transmitting payment card data to 3rd parties can require a major investments in infrastructure.


security concern of user submitted bash command Recently I am building a web service that user input will be used to run a bash command on the server side. What are the security problem I need to take care?

Right now I find one that user could submit things include pipe like valid thing | something bad and my server did run that something bad! I mainly use nodejs and exec from shelljs to build the server.

If you are allowing shell commands to be executed from the browser, then what you are effectively doing is allowing the user to log-in and execute commands on your system as the user that the web-server is running as. Ask yourself if that is what you want to do? The answer is definitely no. No-way. No, not never. In fact, hackers spend a lot of time trying to work out how to do what you have effectively designed in to your system.

You can try and "sanitize" the input, but then all you are doing is asking the hackers to try and find ways around your sanitizer. They are probably smarter than you.

You could try and execute the commands as a user with restricted permissions. Then you are effectively allowing anyone to log-in as that user and execute commands on that system. The UNIX permissions mechanism might protect you a bit.

Finally, you could try using chroot to create a very restricted environment to run your bash commands in. That's quite a lot of work, and there is still the possibility for trojans to be planted in to the restricted environment. If you plan this option, you could look up the makejail command: makejail.

The final option is to not allow users to run arbitrary bash commands,  but instead provide a list of preconfigured commands that you allow them to run, which you know are safe.

Also, you may be vulnerable to the Shellshock bug Shellshock


How to protect against a user using many different IP addresses and creating many accounts? Is it even possible? I have an application that is susceptible of a same person creating many different accounts on different IP addresses. How to fight against this the best? Using 2-step verification like SMS? Any other ways?

There are different approaches, based on how badly you want to prevent users from creating new accounts. While this isn't a comprehensive list, it should give you an overview of what is being done:
Just let them
The simplest approach is to not care at all. If your users want to create multiple accounts, you just let them. While this may sound like "The safest way to ski is not to ski", it is indeed how some services operate. Not every user with multiple accounts has those for malicious reasons. For example, you could create a second Stack Exchange account for a question that you may find embarassing or for which you may have personal reasons as to why you don't want to have it connected to your other account.
Tie registration to a difficult-to-obtain factor
Phone numbers aren't as easy to obtain as they used to be. Back in the day you could buy 20 pre-paid sims with individual phone numbers at the grocery store and nobody would bat an eye. Okay, maybe the cashier would look weird at me, but she doesn't get paid enough to care.
These days, even prepaid SIM cards are more difficult to come by, so an attacker who wants to have lots of different accounts has to go through significant trouble to get them. If their costs to get a new account are higher than their expected gain, it'll not be worth it anymore for them.
Make them pay for a new account
You could tie accounts to licenses. As such, if a user wants to register 10 accounts, they need to buy 10 licenses. While obviously this strategy doesn't work for every kind of service, it does indeed work for some kinds.
Cheating in an online game, for example, becomes less desirable if you need to pay 40€ for a new copy of the game every time you are banned for cheating.
Analyze their behavior
This approach requires considerable investment, but you can build a system that looks out for anomalous behavior and flags it for manual review. For example, if two accounts constantly and almost exclusively upvote each other, then you can be pretty sure that those are sockpuppet accounts.
Of course, the actual implementation of such a system is difficult and will include lots of false positives and false negatives, but depending on how badly you want to stop people from using multiple accounts, it may be worth it.


How vulnerable am I on a unencrypted public WiFi network? I am enrolling myself into a college. College provides a Public WiFi Access Point, to access internet through its network, which is unencrypted (No password). As being a programmer for last one and a half years, I know of some common attacks that any noob will want to try on public network (Packet sniffing using wireshark, etc.) but I don't know how these attacks work. I just want to know how much vulnerable I will be to these attacks on this network. Also, how can I make my Machine isolated from these attacks?

Also if somebody could tell me the possible points of data packet interception, it will appreciated.

I will running Linux Ubuntu 11.10 + Windows 7 Ultimate on my machine.

If you are on unsecured WiFi, all of your internet traffic is broadcasted for everybody nearby to see. This means that any traffic to/from your computer that is not encrypted at another layer (such as SSL/TLS or SSH) will be visible, which can expose sensitive data, such as usernames and passwords, or authentication cookies.

In addition to passive eavesdropping, malicious individuals may be able to intercept and modify traffic to your computer (by tricking you into connecting to a spoofed WiFi network, or by using a mechanism such as ARP spoofing) They could then do nasty things like replace legitimate downloads with malware.

In truth, these are concerns in wired networks as well, but open WiFi just makes things easier (the attacker doesn't need to plug into an ethernet jack).

To mitigate the risks, use SSL/TLS whenever possible, and if you are really worried, use a VPN service, or better yet TOR


How to set up a server for files? I have a specialized software that I have created that can generate gigabytes worth of random data in seconds. I want to put all of these randomized, large files into a location to where it can be accessed by 3-4 different computers in my workplace. These files are for fuzzing, so that the computers can take those files and put them directly into the program (it's okay if they need to download it, but it's not preferred.) It can be a local server (e.g. a RAID array on the network) or a remote server (dropbox). How would I go about setting up a local or remote server, and which one would be more efficient?

The actual, clear question:
How can I go about setting up a local or remote server for mass file storage, and which would be easier for my team?

An Apache server can be hosted and the random file can be targeted to be created in the /var/www/html folder with name random, hence all other machines can access the random file with wget command like the following:-

wget random-machine-ip/random


Authorization expiration without reliable clock / time I've been looking, but I think its impossible to find a pairing solution that has the benefits of authorization expiration and renewal (like x509 cert expiry and OAuth expires_in), but that works without a reliable clock.

I want it because renewal is a chance to phase out vulnerable crypto algorithms and keep active authorizations up to spec. The catch is the system I'm implementing this in can't reliably get to NTP servers and it has no battery clock to preserve time through reboots (every few days it reboots), so determining if an authorization is still valid is practically impossible.

Is there a solution?  Maybe there are alternatives to get clients to renew?

Your question first sounds ironic, because you seem to not want to use or trust NTP while I assume your system is connected to the Internet.

But what if we assume that you do not trust you connection to the Internet and fear a MITM attack or other tempering. This would render the NTP indeed useless. But with preshared initial certificates, your primary system could work. And you will have to trust (at least some of) your successfully verified communication partners.

Here, you have still an option for the expiration feature: you can ask your other valid peers periodically for the time (sort of reimplementing NTP in your application). This should yield you a clock with at least a precision of some seconds (or better).
If you reboot you can save the last time, and asked for the time as soon as possible. However, if you reboot your system within minutes, you still maintain a clock with a precision of minutes (So your clock on a freshly rebooted system never derivate for the actual time further than the time it takes to reboot). Since certificates are usually issued for about a year, a precision of minutes a perfectly fine.

If you mean your problem is, that you do not have a something to count real time, you still can go with a logical clock. So you can e.g. count how often a certificate is used (signing/verification) and reissue a new one if a threshold has been exceeded or expire the certificate if used further. You can either count this per certificate or for all together.


Public AP: How to reduce vulnerability window between Captive Portal and starting VPN? I always use a VPN on my Mac when I access over public APs (such as coffee shop free WiFi)

How much should I worry about the window of time where I am in the captive portal (the agreement screen) and have not yet started my VPN?  My hunch is "lots".

What are some best approaches when you are tempted to use a public AP?

Would it be something like:

Don't have any browser tabs that will try to refresh before you get
the VPN started
Minimize the number of background processes that will try to connect

I suppose another approach is "punt on public AP whenever possible, and tether to a VPN connection over your phone instead".  Chews up data though.

What do the more security-savvy folks advocate?

I suppose another approach is "punt on public AP whenever possible, and tether to a VPN connection over your phone instead". Chews up data though.

You have basically two strategies for your risk (surfing on a public AP).

Elimination: Not using it
Mitigation: Taking precautions to reduce the probability and impact of having information disclosed.

  How much should I worry about the window of time where I am in the captive portal (the agreement screen) and have not yet started my VPN?

VPN will just help you by encrypting your data traffic, which I understood as your major concern when surfing on a public AP. You will be unable to surf anyway until you pass the "captive portal", so I don't see a lot of risk here from a browsing perspective, as long as the only tab you have opened is "agreement screen".

However, once you boot your Mac, some of your applications are very excited awaiting for a network connection. As soon as you connect to the public AP they will try to connect to the Internet (which will fail since they will be probably faster than you opening the "captive portal". Depending on how they were built there is  a risk of revealing information. e.g.:

Password in an url [Caught by a sniffer]
DNS spoofing [An application pretending to be the one your application is expecting]
Browser tabs previously opened or installed addons [Although here you could be protected by a time-out])

  Other considerations

You are heavily focused on the disclosure of data in transit, however there are other risks when connecting to an unknown AP.

However keep in mind (one example of many others) that someone could by scanning your ports in order to attack open ones which have vulnerable applications listening to it. VPN won't help you here.


Is there a point in restoring from backups if you don't know where the virus came from? It's been happening more and more frequently I get viruses with no idea where they come from. I have recent backups, but I don't know if there's a point in restoring since I would just install the same applications and copy over the documents I've been working on. MSE didn't detect anything and I ran combofix and it seemed to have cleaned the infection. Should I may as well keep using the system? FireFox was hijacked but now it's back to normal, however I.E. no longer works.Cursors and crashes!

If you are unable to identify the virus in your backups and you need the data, I would suggest carefully pulling out just the files you need from the backup and install software again on a clean build.

It is still possible the virus could slip through, but if you restore data rather than state, the file still has to be executed in order for the virus to become active again.

You could also try restoring data to a VM and try pulling data out from a safer container that would likely protect your system from re-infection.  It still isn't an exact science if you can't find a virus scanner that can identify the infected files, but it does at least reduce the risk a bit.


Chrome showing SSL warning about SHA-1 when the sites don't use SHA-1 My version of Chrome on an iMac (latest 43.0.2357.130 (64-bit)) is showing an SSL warning for well-known sites (Hackernews, GitHub, DigitalOcean):

  This site uses a weak security configuration (SHA-1 signatures), so your connection may not be private.

However, when I view to the same sites on my other computer MacBook Pro, same version of Chrome and nearly identical setup, I am not getting this warning. Also, my Chrome extensions are synced to both computers, so it is not a rogue browser extension.

Any other ideas and places to look? I'm thinking it is a problem inside the keychain on my iMac.

This seems to be a bug in Chrome.

Root CA Certificates are often still SHA-1 certificates, which is not a security problem (and also not considered a problem by Google: http://googleonlinesecurity.blogspot.ca/2014/09/gradually-sunsetting-sha-1.html), yet Chrome spooks users with the warning - even when the only SHA-1 certificate in the chain is the root CA certificate.

It looks like this bug only affects OS X 10.11 El Capitan:
https://code.google.com/p/chromium/issues/detail?id=499506


Rest WebService with signed requests in Java I'm currently implementing a rest web service with Spring+Java+Tomcat and a cmd client to access it. The most important requirement is to restrict the usage to authenticated users - encryption isn't that important.

Because I can't guarantee that the service is accessed via TLS, I can't use Basic Authentication with username and password.

My idea is to do the following:

Get a nonce from the web service - that's changed after each request
Calculate a signature with DSA of (request + nonce)
Add signature to HTTP header and check it in the web service

How I would create the signature:

// To generate the keys
KeyPairGenerator keyGen = KeyPairGenerator.getInstance("DSA", "SUN");
SecureRandom random = SecureRandom.getInstance("SHA1PRNG", "SUN");
keyGen.initialize(1024, random);
KeyPair pair = keyGen.generateKeyPair();

// Per request
Signature dsa = Signature.getInstance("SHA1withDSA", "SUN");
dsa.initSign(pair.getPrivate);
dsa.update(...)
byte[] signature = dsa.sign();

To check the signature:

Signature sig = Signature.getInstance("SHA1withDSA", "SUN");
sig.initVerify(pubKey);
sig.update(...)
boolean ok = sig.verify(sigToVerify);

I hear so much about don't implement your own security, which is why I would like to know whether other people see something I don't.

Does someone see a major problem with this approach?

First, the nonce you get from the web service must be cryptographically secure (unpredictable) and used only one time to avoid replay attacks.

Then, there is nothing wrong with this approach, as soon as the web service stores the public key from the client and is able to verify its authenticity.

Moreover, one drawback to consider, is signature verification performance cost. (see: Statistical data about the performance of various encryption algorithms)


Why do phishing emails have spelling and grammar mistakes? Are the spelling and grammar mistakes in phishing emails done on purpose? Is there some wisdom behind it? Or they are simply indicative of the fact that they've been written by someone who does not natively speak English?

This may well be for the same reason as many scammers rely on the tired old 'Nigerian Prince' strategy: by self-selecting for gullible targets, they can be more efficient.

In phishing, as in scams, sending the initial batch of emails is the easy part.  The hard part is coaxing information out of the target (which can require a concerted exchange of emails).  That can represent a significant investment of time.

As a result, it's really important to ensure that the people you correspond with may actually give you the information that you're after.  It can therefore be advantageous to send a badly-drafted email, on the basis that the people who respond to that are likely to be gullible enough to be phished.

(I would probably draw a distinction between these broad, drag-net approaches and targeted phishing, where you're much more likely to see carefully-crafted and legitimate-looking emails.)


Authenticating a user by verifying a signature Background

I'm setting up an API which will be used primarily over HTTPS (only calls not needing any security what so ever is available over HTTP). Some aspects of it need to be accessed only by authenticated users. To allow this without using passwords each user possesses one or more RSA keypairs. The public key is kept on the API server.

When the user want to be authenticated they sign the current timestamp with their private key and send it, the timestamp and an ID to what keypair was used over to the server.

The server verifies that the message (the timestamp) was signed by a user with the corresponding key.

The server verifies that the timestamp has not surpassed a certain amount of time and returns a JWT token signed with the server's private key which will be used later to authenticate the user.

Concerns

The timestamp (which acts as a nounce(?) and a way to restrict access according to time) should not be sent along with the authentication request to the server, since knowing what message was signed the key could be reverse engineered.

An uncautious user could misplace a signed key which would practically be just as bad as losing a password if not worse.

Question

Is it wrong supplying what "nonce" that was signed along with the request or should the server already "know" (via some previous exchange)?

Does using the timestamp as a message when creating the signature defeat rogue digests? I.e. is it enough to make the digest unusable after the expired time - since the message can't be altered without not passing a verification?

It is unclear to me exactly why you are implementing such a complex authentication mechanism. Homegrown authentication solutions are notoriously difficult to get correct. So my first thoughts are to try and steer you to more standard mechanisms.

In summary, my recommendation is to use username/password for authentication. If you have a good reason not to do that, use SSL mutual authentication. And if you have a really good reason for not doing that, use your suggested method with changing the time stamp to a server-side generated nonce.

Details follow...

Option 1: Simply use username/password for authentication. You don't mention why you're not choosing this more common route. Perhaps you are hoping for a higher degree of security?

Option 2: Use TLS/SSL mutual authentication. This is a tried and true standard supported by nearly every web browser and TLS library. In mutual auth, the client has a private key and an X.509 cert, similar to the server. When the SSL connection is initiated, it uses not just the server's cert, but the client's as well. Both sides of the communication can confirm the party they are communicating with. Unlike the server's cert, the client's cert doesn't need to be signed by a certificate authority. This means it could be a self-signed cert or created by your own certificate authority. All that matters is that the server can validate that it is the right cert for a specific user. My preference is to simply store the cert (really the cert's fingerprint) in the user database. This allows for easy revoking as it just means deleting the revoked cert from the DB.

Based on the limited understanding I have of your project, I see no advantage to your proposed solution over mutual auth SSL. You are recreating parts of the mutual auth protocol instead of just using an established solution.

Option 3: Your homegrown solution. I see no problem passing the nonce in the same message as the signature. As this is done over SSL, only the client and the server could see this information. So it doesn't matter if the server gets the nonce in the message or "knows" the nonce from an earlier part of the conversation. Either way, the server has both the nonce and its signature and nobody else should have access to this information.

As far as defeating a replay attack (what I assume you mean by "rogue digests"), I'm not thrilled about using a client-side generated nonce. I think it is more secure to have the server pass the nonce to the client and then let the client sign that data. This requires an extra round of communication, but as we're discussing long-lived conversations in this scenario, I think this should be OK. Once you move to using a server-side chosen nonce, you can just use a cryptographically secure random number as the nonce and store this nonce on the server. The server can then handle the lifespan of the nonce. Also, I'm not a big fan of using time stamps that span computers as, even in 2016, clock synchronization between server and client can be a hassle.


How can Linux be secure if it allows for open source contributions from the public? From my brief understanding of Linux, developers from around the globe submit code to be included into a Linux update. It's then reviewed by security administrators. When approved, it's passed onto Linus, the founder of Linux for his final approval.

With all of this code being submitted by unknown developers throughout the world, how can the security administrators make sure that there isn't any backdoor scripts being added onto the OS? Aren't there like 15 million lines of code? Do the admins of the OS really understand every line of code and know for sure that people haven't submitted something that could corrupt the system such as malware, backdoors or spyware?

You are misunderstanding how open source software development works. Not just anyone can modify the kernel, so no "unknown developers from around the world" are submitting mysterious lines of code. In order to make changes directly, you have to be hired by the Linux Foundation or another organization that has access to commit privileges, not just pass a brief check. Everyone else can only suggest improvements (often in the form of a patch) on the public mailing lists, and hope that the official developers will accept their suggestions and make the changes on their behalf. The review of patches is quite intense and patches often have to go through many revisions before being accepted, sometimes with each line being criticized (often for the most trivial things).
This is not so different from closed source development. You could argue that anyone can make modifications to Microsoft Windows simply by looking for a job at Microsoft. The only difference is that open source software is more transparent about their development process.

With all of this code being submitted by unknown developers throughout the world, how can the security administrators make sure that there isn't any backdoor scripts being added onto the OS?

Everything added is reviewed. The only way to get a backdoor in would be to provide a patch that looks good, but which has an exploitable bug that you are aware of. This is possible, but quite unlikely. Developers don't need to be malicious to introduce bugs at staggering rates!

Aren't there like 15 million lines of code?

More, actually. However a large portion of this is for device drivers which you will never even use. The Linux kernel is monolithic, which means hardware-related code is put in the kernel. The core of the kernel itself is actually not that big. It only looks big when you count the fact that it also includes code from obscure karaoke microphone drivers that are not even present in your kernel.

Do the admins of the OS really understand every line of code and know for sure that people haven't submitted something that could corrupt the system such as malware, backdoors or spyware?

No, although some particularly savvy sysadmins do have a good knowledge of how the kernel works internally. There are quite a few eyes on the code in the Linux kernel looking for bugs. It is hard for them all to hide. Yes, it is possible that a bug was secretly introduced (after all, it was attempted and foiled a few times), but the painful truth is, such intentional bugs would be a drop in the water compared to all the naturally existing bugs that find their way into such a huge codebase.


Can you sign using a digital certificate itself? Googling I saw several lectures saying that it is possible to sign using digital certificates. I am confused about that, because according to my knowledge it is possible to sign only using the private key, where digital certificates are used during the signature process?

Just a matter of imprecise language that should be understood by everyone involved.

You sign using the private key that only you have. The public key is not used, and the certificate is not used. In fact, maybe there is no certificate using the public key. The verifier verifies the signature using the public key, the certificate is not used. But the public key is just a number (or two numbers). It is inconvenient to handle the bare numbers. So often the public key is carried around with some metadata that says what the public key is for. That is a certificate.

Maybe it just says "juaninf's public key" and is self-signed (has a signature attached made using the private key matching the public key of itself).

Maybe at work it has a note signed by your boss that says "This is the public key of juaninf, I hired him to work for me on 2019-06-23, I am the manager of department D at corporation C, here is a signature from the CEO of corporation C attesting to this fact". And the automatic doors at the building can test this. And your private key is in an unclonable smart card.

If you click on the lock next to the URL in your browser, you can see the TLS certificate for the site. In the certificate, you can see the public key. You can see the certificate, therefore you have the certificate. But you do not have the matching private key. So you can't create a new signature for the public key in the certificate. So you can't do MitM attacks on other visitors of the site. To do MitM attacks, you would need to have the private key matching the public key in the certificate to sign DH key exchange messages (or decrypt encrypted secrets in obsolete configurations of TLS).

Sometimes it is important to be precise when saying "I have the certificate" or "I have the certificate and private key". But often it is obvious from context what is needed.


How to communicate how secure your system is to your employer's clients Businesses have to collect information about their clients, and clients often want assurance that their information is secure. What is the accepted way to concisely and clearly communicate how secure the systems are that are transmitting and storing the client's data? From what I can tell, it sounds like citing compliance with a security standard (such as ISO27001) is the way to go when speaking with a security professional (is that correct?), but does anyone have any experience with successfully explaining "how secure" your system is to a "lay" person with little-to-no understanding of information security? Just "Our business meets or exceeds the accepted security standards for our industry"? Is that enough information? In your experience, how much detail do most people want?

Background information: our business collects sensitive data about our clients as part of an accreditation process for services they want to qualify for with a third party. Most of these clients are small business owners, e.g. plumbers, dentists, restaurant owners, etc.

This question might be subjective, but it falls into the realm of "good subjective."

Edit

This is a not a duplicate of How to get top management support for security projects?. That post deals with communicating with others within your organization, while this question is about communicating with people outside your organization, which is much more sensitive. You can explain to a superior why your system isn't "100% secure", but you have to be more diplomatic with a client, while still being concise.

The answer to your question depends on a number of factors including,

"Who are your clients" - Different companies will want different levels of assurance, for example a bank sending financial data will (hopefully) want more assurance than a coffee shop sharing menus.
"What data are you processing for your clients" - Again this will affect the answer, if there are regulations in play those may lead you to have to provide specific forms of security attestation.

With that said there's a number of strategies you can use, none of them (in my opinion) perfect.

ISO27001.  This is a common one as it's internationally recognized.  As you've done it you'll likely have found that the devil is in the detail, things like the scope of which bits of your business you certify will greatly affect how easy it is to achieve.  Also note that ISO27001 is perhaps more about documenting what you do well rather than necessarily doing all the right things, and that point is quite well known, I'd say.
3rd Party Assurance.  You can get a 3rd party to do security reviews and provide summaries of these which you can give to customers.  this is commonly seen in the technical security world (e.g. Pen Test Reports) and also to an extent elsewhere (e.g. SAS-70).  How convincing these are may depend on what testing you actually have done and how savvy your customers are (i.e. can they tell the difference between a detailed test and a quick superficial test)
Let your customers audit you.  Can be appropriate (or even mandated) for large clients.  has the upside of them being able to test exactly what matters to them, and the downside of having sets of auditors trooping through regularly asking awkward questions.

Ultimately however none of these really work with non-savvy customers.  There is a massive "market for lemons" in security where consumers cannot tell the difference between two companies, generally 'cause they all claim perfect security (ever see a site say "hey security isn't that important to us, but give us your data anyway") and there is no mandated effective impartial standard.

With a savvy customer, I'd recommend asking them what's important to them about security and how they would like to see that proven.


Using bcrypt in chrome extension I am developing a chrome extension for this non profit. Im also working on the server side component as well. Im not a full time developer so most of my knowledge has simply come from years of collecting random information. One thing this program needs to do is login to the server and retrieve a code unique to the user. Luckily from how its working out in my mind we dont need to store the password, only retrieve and store their unique ID. However we will need to login to get that ID.

So my question, is if I use bcrypt in javascript to hash the password within the extension and then send the email + hash over to the server (via https of course), is there any security risk here? Im not thinking of one off of the top of my head but I just figured I would consult a few people who live in this world on a regular basis. Thanks!

Is there a security risk?  No.

Is there a security advantage?  No.

Using HTTPS means that the password is protected in transit, and that it is being sent to the server you intend to.  Hashing the password client-side and sending the hash gains nothing: an attacker in a position to look inside the SSL tunnel and steal a plain-text password (eg. malware installed on the client) can instead steal the hash and pass it when impersonating the user.

As a side note, there are problems with hashing or encryption in Javascript.  Using a browser extension rather than in-page Javascript avoids many of them, but there's still a speed issue: Javascript is slow compared to native code, so you can't afford anywhere near as many rounds of bcrypt hashing.


How much safe is "the cloud" ? What is the simplest and safest approach in storing everyday personal data? You use multiple computers in work, home and mobile devices (android, ipad). You want to share your files between devices and you use physical sources: an SD card, dvds, a usb stick etc. with every flaw that it implies: losing the physical storage device, you lose all your data. This can happen by theft, fire, loss or whatever.

So one sunny day, the cloud appeared. Everything yours is stored "somewhere" and even If you burn your computers and bury them 6 feet underneath the ground, you will still be able to work and retrieve all of them. But has it really solved anything?

As I see things, some kind of balance exists between "physical safety" and "virtual safety". You compromise the private safety of your own home and physical devices to give your personal data to a stranger, by signing an agreement that he will be trust worthy. But that's not only the deal.

Authorised sources (like "research" government agencies - theoretically) could be able to bypass this agreement and "take a look" in your data. Hackers, your jealous "best" friend, or your neighbour could gain access to your data, accidentally or not. Easier than breaking through your home, breaking the lock of your drawer and cracking the encryption of your laptop !

So finally, what is the point? Most of the people do not care or do not have the knowledge to understand all that. I see that the cloud has taken a step forward and at the same time 10 steps back. I do not own confidential illegal data, but I won't like to see my family photos fiddling around somewhere in the chaos of the internet.

I could use an encrypted truecrypt schema backed up in two or three sources, but it's not that easy for everyday work.

Taking about sanity, what is the safest approach?

The answer is very complex and depends on many factors:

which kind of information would you like to store in a cloud,
how much you care about them,
how much you will be affected in case of those data disclosure,
how much money and time would you like to spend on your data storing solutions.

Personal data sounds like important stuff to me, so I would suggest you to not store you data in one of big-company, free services, such as Dropbox or Google Drive. Maybe it seems to be a bit too preventive, but big organisations are well known for their curiosity of our data. So I would choose one of commercial services, usually they pay more attention to security. But of course not always.

The second thing is to encrypt your data, with use of some well-known and tested tested solution. Most security-related people consider TrueCrypt as fine tool. If will choose some other tool remember to check which kind of algorithms it use. At the moment AES-256 (symmetric), RSA-2048 (asymmetric) and SHA-512 (hash) are consider secure enough.

If you have plenty of time, some Unix skills and a bit of infrastructure you can also install you own cloud with use of such software as ownCloud or SparkleShare.

EDIT: I just found a another similar software called SeaFile, they just release version 2.1.

There are also solutions called Virtual Private Cloud, which run partially in your infrastructure, but usually they are for commercial use. Please see the list of virtual private cloud providers.


What actions are needed on the server when a intermediate certificate expires? I understand the following:

An end-entity certificate is installed on the server and a new one needs to be installed by the webmaster when it expires
A root certificate is installed on the computer and a new one will likely come in an OS update for when it expires
A intermediate certificate is installed on the server, but what happens when it expires, does the webmaster need to get a new one of these too?

I need to know how an immediate certificate gets updated, does the webmaster get sent a new one to upload to the server with its normal end-entity certificates?

Validation of the end certificate would fail. However, intermediate certificates are typically valid for a much longer period of time than regular certificate, often 10 years. This enables the maintainers of the intermediate certificates to introduce a new intermediate certificate way before the old one expires, but after all end certificates expire, so in practice this situation shouldn't occur.


where should I store my application password? I have a Windows application that does not use a database and is not on the Internet. It contains very important data (data loaded from encrypted files). The user needs a password to enter this application.

Where should I safely store the application password? (also there is a few short string data that need be stored (files addresses)). The application is run on Windows XP and later versions. I use C#.

Note: I do not ask how to store password. I know it should be hashed and should use salt for it. See this post.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa374789(v=vs.85).aspx

  Developers who write for Windows can use the Credentials Management
  API including Credentials Management User Interface (UI) functions to
  obtain and manage credential information such as user names and
  passwords. These functions request Windows account information to be
  used instead of the credentials established while logging on. Such
  requests typically occur when the logon credentials do not have
  permissions that are required by the application. The Credentials
  Management UI functions provide interfaces with the appearance of the
  Windows user interface. These functions include customizable options
  that add user's information to the user's credentials store.

In your data are really impotent consider using hardware based solution (ex. Smart cards, TPM).


Is it safe to be showing my WAN and LAN IPs in my email headers? I don't know how to hide my LAN IP from my email recipients.
My LAN IP shows up next to my WAN IP in my outgoing email headers (sent to my other accounts and viewed by me). I have not seen emails sent to me showing other people's LAN IP in their headers that I can recognize. Some people have said they also see their LAN IP sent. Maybe a trait of Thunderbird client? It has no options to hide LAN IP. Thunderbird forum has no solutions. Any ideas?

Your local IP address is pretty much useless outside of your network. The only time you need to worry about if someone has your internal IP address is if they also have internal access to your network, either physically or via a Virtual Private Network (VPN). It's very hard to initiate a conversation with a device inside a network from outside the network, unless the network is willing to forward the connection (e.g. to a web server). The sole exception, of course, is if you use port forwarding or a demilitarized zone, in which case they don't need your local IP address anyways, since having the WAN IP is sufficient.

Also, you can read bug 417942 where this is discussed. Basically, Thunderbird is doing what email does: identify the path that the email took from start to finish, so it can be traced back/debugged/etc if necessary. It appears that Thunderbird only sends an IP address if there's no host name available, so if you were willing to set up a DNS server in your private network and assign your devices to host names, you could avoid having your internal IP address exposed.

The last comment basically sums up why this behavior is okay:

  ... Read RFC-2821:  "An Internet mail program MUST NOT
  change a Received: line that was previously added to the message header.
  SMTP servers MUST prepend Received lines to messages; they MUST NOT change
  the order of existing lines or insert Received lines in any other location."

  It also specifies what goes into the Received: line.  Read section 4.4 of RFC-2821, and then tell me why we should violate this standard.

  ... The whole point of precise information identifying the host is so that the exact path taken by the message, and when, maybe clearly determined for tracing and diagnostic purposes.

  ... Thunderbird complies to the standard, and this is correct behavior.  I'm closing this bug.

In other words, any client that does not disclose either a host name or IP address is not in line with how the email protocol was designed to work.


Difference in between salt and random padding in cryptography I would like to know what is difference in between using salt and using "random padding" in cryptography. I am familiar with term salt when we use it with hashing. How does "random padding" differ from "salting" ? It might be the case that these terms are used in different context, but they mean the same or do they ?

Wikipedia article on random padding and salting. I've read both wikipedia articles but i see it as they are the same but they are used in slightly different contexts. Maybe someone who is more familiar with these terms could explain on what is going on ?

When we use a block cipher, that has a certain block size as DES has 64-bit and AES has 128-bit block size. With the modes of operations, we support larger size of plaintexts than the block sizes.

When the plaintext size is not divisible exactly by the blocksize of the cipher, some part must be filled for the last block (padding) and after the decryption must be removed (unpadding). There are various types of padding; as;

xxxxxxxxxxx1000000000 //bit padding
xxxxxxxxxxx0000000005 //ANSI X.923,
xxxxxxxxxxx0505050505 //PKCS#5 or PKCS#7 padding

The first one can be removed by searching the first 1 from the right.
For the second one, there must be x (in number) 0x (in bytes) appended to the plaintext. Adding just random bits will not help, since we cannot resolve while unpadding.

Note: padding is also required in public key cryptography.


openssl ECDHE-RSA... cipher suite selected while using RSA server cert and ECDSA client cert The scene:

s_server using RSA certificate.
s_client using ECC-ECDSA certificate.

Client authentication is required (option -Verify set on s_server)

Cipher-suite selected after handshake is ECDHE-RSA-AES256-GCM-SHA384.

So, i don't completely understand how the type of certificate (RSA-DSA) affects the cipher-suite selected (regarding the authentication part of the cipher-suite).

Could it be that the server's certificate set the type of authentication used?

Could someone explain how the server/client certificates affect the cipher-suite selection?

"ECDHE" means that the key exchange will use the Diffie-Hellman algorithm (over elliptic curves) with freshly generated DH elements; the last "E" stands for ephemeral. So while DH produces a shared key, it will work with randomly produced values, and nothing in DH will ensure authentication: the client has no way to know whether the DH public key it sees really belongs to the intended server.

To bring back server authentication, something else is needed. It is a signature: the server digitally signs its half of the DH key exchange. That signature uses the key which is in the server's certificate, and thus the signature algorithm depends on the type of that key. In "ECDHE-RSA", the "RSA" part relates to that signature: it says that it will be of type RSA (and implies, of course, that the server's certificate contains the corresponding RSA public key).

There is no such mechanism for client authentication. When the server requests a client certificate, the client will have to compute a signature and send its public key (as part of its certificate), but there is no relation between that client certificate type and the cipher suite. The reasons for that are:

Client certificates appear later in the handshake, after the cipher suite selection. When the cipher suite is chosen, the client does not yet know whether a client certificate will be requested at all.
A SSL server, in general, must be able to answer to the whole World, but when the client connects, it knows what server it is talking to, and can select an appropriate certificate in consequence (the server also sends a list of CA names to narrow down the client choices). Client certificates are a rarity in a Web context; in all generality, SSL servers ask for client certificates when they know that the clients already have certificates of an appropriate type (e.g. a bank server will ask a customer's certificate only if the customer is part of a program in which the bank ensured distribution of the said certificates). Therefore, there is no need for a dynamic negotiation of the client certificate type.

The cipher suite selection is all about choosing algorithms which are supported at both ends. If the server must sign, and the client verify, then the client must be able to understand the signature algorithm and thus its key type.

In practice, the client sends a list of supported cipher suites, and the server selects one of them -- a cipher suite that, of course, corresponds to the algorithms and key types that the server is going to use. Theoretically, the list sent by the client is ordered by "preference" and the server is supposed to honour that order, i.e. choose the first cipher suite in the client list that also fits the server's abilities. Not all servers are that courteous.

See this answer for an introduction to SSL/TLS.


Authenticating users to Web Apps without sending password — can anyone suggest improvements? I have been interested in implementing authentication method for a web app that is run in modern browsers, without having to send the password over the wire.

Can anyone suggest improvements or even tell me whether or not I am going wrong.

The authentication is done over an unsecured HTTP connection using AJAX.

My current understanding of an authentication protocol implementation

Server has a users password that was hashed using bcrypt and stored during registration.

User enters id and password. A XMLHttpRequest is sent to the server to begin authentication, X-R1 is a random integer created on client.

GET /auth/{id} HTTP/1.1
X-R1: 123412341234

Server gets values.

ServerPassword - users bycrpt hashed password from password database
X-Salt - extracts the salt from the ServerPassword
X-R1 - from client in the request header
X-R2 - randomly generated integer on server.

Server creates values

X-Session - session key, concatenating X-R1 + X-R2 + id it then one way hashes this string
Verifier - shared secret, concatenating X-R1 + X-R2 + ServerPassword and then one way hashing this string.
Saves these values to a session store.

Server response.

HTTP/1.1 202 ACCEPTED
X-R2: 432143214321
X-Salt: $2a$10$rBV2JDeWW3.vKyeQcM8fFO
X-Session: 92429d82a41e930486c6de5ebda9602d55c39986

Client gets values

X-R1 - same value from before sending the request.
ClientPassword - plain text, what user entered.
X-R2 - from server sent header
X-Salt - from server sent header.

Client creates values

HashedPassword - created using a JavaScript implementation of bcrypt by using the ClientPassword and X-Salt
Verifier - Concatenating X-R1 + X-R2 + HashedPassword and then one way hashing this value. Client uses a JavaScript implementation of bcrypt to hash the password that the user entered with X-Salt's string.

Now the client and the server both think they have the same verifier so to confirm this client sends a further request but this time hashing the request headers and body with the verifier and then adding 'X-Auth' to the headers with the resulting hash.

POST /auth/{id} HTTP/1.1
X-Session: 92429d82a41e930486c6de5ebda9602d55c39986
X-Auth: ad801198a9fab4e4ef79eb97624a4bf9c78b450a

Server now looks up the X-Sessions's in it's session store. Does the same hashing of the request headers and body and then checks to see if the hash matches X-Auth's value, if so the server assumes the client is authorised and responds accordingly.

HTTP/1.1 200 OK

Client knows server has the same Verifier and stores it in localStorage using X-Session's value for the key, for further requests.

Concerns

I am an average developer and no crypto expert and from my understanding I can not see any issues that might occur with this method.

I can see the great advantages, such as:

The password is never sent over the wire. Prevent MITM from getting your password.
MITM can't modify request as it is hashed with the verifier and then sent.
The server doesn't need to use bcrypt every time a user wants to authenticate.

The authentication is done over an unsecured http connection using AJAX.

I stop you right here. If the Javascript code running on the client side went over unsecured HTTP, then that code could have been altered in transit by any half-competent Man-in-the-Middle attacker. It can then do a lot of evil things, like, for instance, sending a copy of the user's password to some attacker-controlled server.

Client-side cryptography in Javascript works only if the said Javascript came over a secure link, i.e. HTTPS. And if you have that link, then why would you bother any further ?

Apart from that, what you describe has nothing "SRPish" whatsoever. SRP is a Password Authenticated Key Exchange protocol, which means that it grants immunity against offline dictionary attack, something which cannot be achieved with symmetric cryptography tools like hash functions and bcrypt. At best, bcrypt will grant resistance against offline dictionary attacks, meaning that an eavesdropper, spying on a connection, may learn enough to "test passwords at home" but will suffer for each test.

SRP does "better" through some extra mathematics. See the RFC. There are modular exponentiations in there.

SRP-with-TLS makes sense only because it works at the SSL level directly, is done by the browser, and uses an implementation which is already on the client side. When the browser does not implement SRP at the SSL level, then you are back to the "usual" setup with normal SSL (with a server certificate), and sending the user password "as is" through the SSL.


Is it safe to use public key encryption to authenticate myself? The idea is to send an encrypted message in such a way that the receiver can verify the sender.  Here is the proposal:

I generate an RSA public-private key pair, and I give the private key to Barry.
I keep my public key secret (!) and I use it to encrypt messages.
When I send an encrypted message to Barry, if he can decrypt it using the private key I gave him, then he knows the message came from me.

Is this secure?  Without access to my public key, but perhaps an eye on the messages, can anyone else fool Barry?  (And does it matter if other people see the private key?)

If not, what kind of approach should we be using to sign encrypted messages, without having to perform a multiple-trip hand-shake?  (Preferably still using RSA.)

The common way to sign and encrypt a message is to... both encrypt and sign it!

That means that you give Barry your public key, and he gives you his public key. Then to authenticate a message, you encrypt it with your private key, and to encrypt it so that only Barry can read it you encrypt it with his public key. If you want both, you use both passes one after the other in a consistent order.

In fact that is more or less what MIME mailers implement, except that the encryption uses a unique symetric key, and only that key is encrypted with the public key of the recipient, and for authentication, only a hash of the message is encrypted with the private key of the sender. Because it is much simpler and as secure...

Alternatively if both parts must be kept secret, do not use public key and just share a secret that is used for a symetric encryption.


Change 'Key Usage' of a certificate Is it possible to change the 'Key Usage' property of an existing ssl certificate of a web site? Our goal is to host a web service so that a third party can integrate with our solution, and their requirement is that our ssl certificate has 'Data Encipherment' in the 'Key usage' field. Currently our ssl for the site doesn't. Trying to see if it is as simple as somehow editing existing certificate without having to buy a new one.

Certificates are signed. The signature covers all the certificate contents, including the Key Usage extension. You cannot change anything in the certificate contents, not the smallest bit, without invalidating the signature. So no, you cannot "change" a certificate. Certificates are immutable by construction.

Your certificate vendor might accept to give you, or sell you with a discount, a new certificate which fits your requirements.


APK Signature Scheme v1 vs APK Signature Scheme v2/v3 What are the security implications of using the APK Signature Scheme v1 instead of the APK Signature Scheme v2/v3? Are there any additional attack vectors for v1 except for direct attack vectors in an APK verifier? With direct attack vectors mean things like DoS directly in the APK verifier.

Let me quote the official docs:

  v1 signatures do not protect some parts of the APK, such as ZIP metadata. The APK verifier needs to process lots of untrusted (not yet verified) data structures and then discard data not covered by the signatures. This offers a sizeable attack surface. Moreover, the APK verifier must uncompress all compressed entries, consuming more time and memory. To address these issues, Android 7.0 introduced APK Signature Scheme v2.

So yes, JAR signing (v1 signature) does have additional attack vector: malicious mangling of the metadata, or of compressed (signed) entries. For example, uncompressing a specially forged entry, which occurs in trusted context, could cause dangerous side-effects for your system.


Web Crypto API maturity for JavaScript RSA encryption? We have been using a JavaScript crypto API to do RSA encryption in the browser. I know all the criticisms on encryption in JavaScript but we have evaluated pros and cons of the solution and the risks are acceptable for us.

In the past we used pidcrypt but now the project is abandoned so I was looking for a standard library and I have seen the Web Crypto API.

The question is how much is it mature the standard especially on mobile devices?

Support for the web crypto API is allright, but not perfect. According to caniuse.com it got 91.5% support:

You'll need to use prefixes for some older browsers, and deal with some inconsistencies in the IE 11 version of the API.
Older versions of IE than 11 have no support at all. But that's only a 0.3% of global usage.
Your big problems are two mobile browsers - Opera Mini (2.3%) and the Android browser (0.8%). They have no support. However, usage of these might vary across the world. Opera Mini, for instance, is big in the developing world but not so much elsewhere.

What's important here is that you need to completely disable your application (or at least the sensitive parts) if the crypto API is not supported. Falling back on something terrible such as Math.random is not an option. Telling 8.5% of your users they can't use your site might off course cause some PR problems...

I'd say you need to have a very special use case for this to be motivated. But you seem to be familiar with the criticism, so I will not reiterate that. Just make sure your problem isn't already solved by the correct use of HTTPS.


What is a good way to authorize a client at a time to perform an action through websockets? I am working on a round based web game where only one client/player at a time can perform an action. Throughout the game every player will have a websocket connection to the server. The client will send simple JSON messages like
{
    "action":"kick_in_the_face"
}

My requirements are these.

Nobody (player,attacker,man-in-the-middle) must be able to fake another players actions.
Ideally it works without the users username/password.
Ideally it works for unregistered users.

Some Ideas I had so far.
Method 1:
Let the server send a hard to guess hash only to the authorized player and let the client send it back in the message like this
{
    "hash":"c99dd3c7c0bb5ed272c3683b1946a95d22a0abfe57284b4ba33592e478e64269"
    "action":"kick_in_the_face"
}

So if the server gets a message with the correct hash it must have been an action from the authorized player. A new hash will be computed for every message.
Method 2: I thought method 1 will be not secure enough. There is still a chance another player might guess the hash. So I thought I could implement it this way

At game start server and client will agree on a secure key (like in Diffie-Hellman key exchange)

Server creates hash and encrypts it using for example AES and the key and will send it only to the authorized client.

Authorized client will decrypt the hash, add the action, encrypt the JSON message and send to server.

Server will decrypt the message and check the hash with the original hash it send.
Although I am not sure if method 2 is actually more secure than method 1 and will prevent wild guessing. Plus I will feel uncomfortable implementing a method to securely exchange keys.

Method 3: Ignore all of that and let the server track the authorized websocket connection. The server will then track the websocket connection of the currently authorized player and ignore messages from all other connections. Is this safe against man in the middle attacks or other attacks? Is it guaranteed that the websocket connection is not hijacked? How would I protect against that?
What method is most secure? Is there another method I should consider? Is this safe against man in the middle attacks or other attacks?

Use Method 3 and make sure to use TLS (WSS protocol).

If one user = one websocket connection, this is enough.

If you want to handle reconnects or want to authenticate some users, generate a random id for each user and transmit this using https. The websocket client sends the id on connect to identify itself.

TLS protects against man in the middle attacks for HTTPS and WSS.


Is generating a random salt for every password-hash but not saving the salt good/bad? I read this related article: Hashed pw storage with random salt
which is kind of related to my question, but in the question and in the answers as well they mention to store the random salt used to hash the password in the database.

Now I'm using bcrypt to hash passwords and upon hashing the password I generate a random salt and hash with that BUT I do not store the salt afterwards because bcrypt can verify without it. Is it a good/bad practice? If so, why?

Can't comment, so I'll answer.
Bcrypt already adds a salt. Is there a reason you want to salt the password twice?

As Steffen Ullrich pointed out in the possible duplicate question (https://security.stackexchange.com/a/184800/178931):

  From a description of bcrypt at Wikipedia: ... The rest of the hash string includes the cost parameter, a 128-bit salt (Radix-64 encoded as 22 characters), and 184 bits of the resulting hash value (Radix-64 encoded as 31 characters) Thus, the salt is automatically included in the output string which means there is no need to add it by yourself.

The hash produced by the bcrypt function contains random salt. This way the salt doesn't need to be stored anywhere else.
Wikipedia has a good article on bcrypt: https://en.wikipedia.org/wiki/Bcrypt


Un-redacting analog redactions on variable width fonts? The FBI currently prints and redacts documents using analog mechanisms. I'm curious to know if anyone has ever researched the accuracy of inferring the possible words or names. Certainly, given the static width of the characters in the variable width font-set, the limited space available, and the likelihood of character sequences, this should be doable.

I believe this was the original document
I believe this document was realigned for the purposes of OCR

Here is a snippet from the document taken from page 61.

Snippet reads,

(U//LES) An identified `<REDACTED>` as of October planned to engage in sniper attacks
against protestors in Houston, Texas, if deemed necessary. An identified `<REDACTED>` had
received intelligence that indicated the protesters in New York and Seattle planned similar protests in
Houston, Dallas, San Antonio, and Austin, Texas. `<REDACTED>` planned to gather intelligence against
the leaders of the protest groups and obtain photographs, then formulate a plan to kill the leadership via
suppressed sniper rifles. (Note: protests continued throughout the weekend with approximately 6000
persons in NYC. "Occupy Wall Street" protests have spread to about half of all states in the US, over a
dozen European and Asian cities, including protests in Cleveland 10/6-8/11 at Willard Park which was
initially attended by hundreds of protestors).

That one little snippet covers the latin characters,

"(),-./0168:<>ACDEHLNOPRSTUWYabcdefghiklmnoprstuvwxyze

I'm sure the others can be be grabbed from the document too.

I took the last few lines (that have no redaction) and overlaid them with a copy of the same text in Times New Roman. I'm convinced that the font is Times New Roman, but that the scan is bad or that something was done to obscure the alignment.

This whole vulnerability is predicated on variable width graphemes. Where many words can be disqualified for the lack of coherency and others for their constituent character size. With variable-width fonts each grapheme has it's own size signature and while there are certainly collisions I think they may do a lot to fill in the blanks. Here are two seven letter words for example -- we can see one of them is substantially bigger:

Looking however at the advance for Times New Roman, I'm not sure how useful this would be.

"512"  : "."
"569"  : "ijlt"
"682"  : "-frI"
"797"  : "sJ"
"909"  : "acez"
"1024" : "bdghknopquvxy0123456789"
"1139" : "FPS"
"1251" : "ELTZ"
"1366" : "BCR"
"1479" : "wADGHKNOQUVXY"
"1593" : "m"
"1821" : "M"
"1933" : "W"

We can see here in the [A-Za-z0-9.-] character class there is 13 different possible lengths.

There are simply too many possible combinations for any reasonably-sized redaction for this to be useful.  You can certainly use spacing analysis to reject possible values, but it's not a practical way to generate candidate values (an advance of 4096, for example, could be any of 60 words; 299 words if you permit 10% misalignment).


Iterated SHA1 hashing and the effect on rainbow table computation Scenario:

1000 distinct keys are each prefixed with the same salt, and SHA1 hashed. The hash output is then iteratively SHA1 hashed x times. Let's start with x is 100.
The specification of the keys is 10 chars length exactly, lower case letters and digits only, therefore the entire key space is not that huge.

The keys should remain secret of course, but it can be assumed the hashes (the final post iteration ones) are public. UPDATE: Assume as well that the salt is also public - therefore not a pepper.

Given the constant salt used here, rainbow tables could certainly be computed for this scenario. My question is this:

Does making x 100, 1000, 100000, 1M make any significant dent in the difficulty of the rainbow table computation? Does a switch to SHA256 make any appreciable difference? Hash functions are designed to be fast after all.

[Yes I know the salt should be different per key, but assume that isn't possible or feasible or whatever.]

From what I've read, it looks like using PBKDF2 (with the requisite high iteration count) to produce the hash seems a better option as it makes the hash calculation much much slower. Again just assume the salt needs to be fixed here.

SHA1 is indeed pretty fast and should be considered breakable, especially when the  space your values come from is that limited. Whether or not increasing iterations will increase the difficulty should be rather obvious: If one hashing operation costs you 0.001ms, 1000 hashing operations will cost you 1ms. Thus, increasing the iterations does indeed increase the difficulty of breaking that final hashed value.

There are however better suited candidates than SHA1 for that job, BCrypt and PBKDF2 come to mind.

If you use such a function and make the iterations a significant factor to make brute forcing unfeasible, you should keep in mind that this could mean an easy DDoS-attack surface on layer 7 if you use that for password checking:

If it takes your server 1s of 100% CPU load to check a login, sending you a login try every second will kill your system easily. If you choose something below say, 1ms (such that an attacker needed at least 32 machines with 16ms ping), it would again be crackable using brute force and some huge EC2 instances.

This, by the way, is because of your fixed length key space.

If your pepper (what you call "salt" in the question) is sufficiently large and unknown, this will increase the difficulty for breaking the first hash significantly, yet after that (if it's known that that's a pepper) it's easy to iterate through the remaining 10 bytes of plain text to break all other hashes.

For example, when your pepper is abcd and the keyspace is only one character, while you have to iterate from aaaaa up to abcda, as soon as you found a, you also found the pepper and thus only need to iterate from abcda to abcdz.


Naive key stretching vs PBKDF2 What are the drawbacks of using a trivially simple key stretching approach such as the below Python example, compared to something like PBKDF2? The purpose is to harden an AES-encrypted file against brute-forcing.

Are there any critical issues with the trivial way? There is no PBKDF2 implementation available in the language I am programming with.

for _ in range (100000):
  key = hashlib.sha256(key).hexdigest()

From wikipedia: Key Stretching:

  ... are used to make a possibly weak key ... more secure against a brute force attack by increasing the time it takes to test each possible key

Since hashes like SHA-2 are designed for speed simple key stretching by using just the hash don't really slow down an attacker which tries to brute-force a key based on the weak input. KDF like PBKDF2 are instead designed to really slow down the attacker by being slow themselves.

While your example does lots of iterations to slow down the computation an attacker could create once a database of all interesting weak inputs and their outputs and use this precomputed values later in multiple brute-force attacks instead of recalculating all values at the time of attack. That's why algorithms like PBKDF2 use additionally a salt to vastly increase the memory needed by such database and the time to create it and thus make it impractical.

  There is no PBKDF2 implementation available in the language I am programming with.

If the language already offers a way to calculate a hash and you are willing to create some KDF anyway then implementing PBKDF2 or other well designed KDF
instead of your own idea should not be too hard.


What are the countermeasures against key cloning? I’ve looked into the techniques of cloning the 315Mhz and 433Mhz remote car keys and I’m wondering what’s the countermeasure one can provide against wireless radio key lock? Since the radio signals do not seem to be unique and to have any sort of tokens or encryption.

Obviously nothing can prevent a broadcast RF signal from being copied, replayed, or studied.  Any security has to be embedded in the protocol itself, but secure protocols are notoriously difficult to get right.  The history of WiFi flaws in WEP, WPA, and even WPA2 shows that even a popular protocol can be broken in unexpected ways.

Current car remotes do have some encryption and defenses, but they're inadequate against modern attackers.

Automakers have relied on third party chips that developed a rolling-code technique about 20 years ago.  They were designed by very smart software and electronics engineers, but not by cryptographers.  (Perhaps they mistakenly thought that if they couldn't break their system then nobody could, but that's now how cryptanalysis works.  This was a common failing in that era.)  Rolling codes are very susceptible to a "Rolljam" replay attack.

Remote control locks have to meet price-point, reliability, convenience, size, power, and performance concerns.  A pair of radios could perform a very secure TLS 1.2 key exchange, but transmitting 8000 bytes over 433MHz using current protocols and electronics would take thousands of milliseconds.  Such a lengthy message would likely trigger dozens of packet resends due to interference, and the typical CR2032 coin cell battery in the typical remote wouldn't have enough power to last a year. (Using WiFi chips and 802.11 to operate the locks would be possible, but I don't know of any cars using this model.)

Modern attackers spread themselves wide, attacking not only the cryptography but the protocols, packet timing, jamming, power consumption, eavesdropping, and OSINT (reading published documentation.)  The advent of Software Defined Radios means that anyone with a $20 radio and a laptop can now attack a system that used to require a bench full of RF gear and a ham radio operator. And the rapid spread of code and intel on the internet means that nothing remains secret once it's been discovered and revealed anywhere.

Attackers have matured greatly since these key fobs were first invented, but RF protocol engineering has not kept pace.

But you asked how you can defend yourself against current attacks?  The glib answer is that it's almost impossible when the protocols themselves are so weak.  Available options are extreme, and don't fit with most people's ideas of convenience or in their budgets.  Here are some suggestions, with the most important at the top:

Buy theft insurance.  This transfers the risk of having your car stolen to your insurance company.  Now it doesn't matter what kind of new attacks people invent, you have a financial defense that always protects you, instead of physical defenses that only protect your car against certain attacks.
Don't use your remote dongle to lock the car doors. Push the button inside the door to lock them when you leave. This prevents the Rolljam attack from working.
If your current key dongle can open your door locks by RF proximity, don't use the remote buttons on the dongle at all.  Again, this prevents interception at a distance, including Rolljam.
Leave the dongle at home and not use your RF buttons at all; use only the mechanical keys and locks that came with your car.  Note that picking car door locks is a skill that many people practice just as much as hacking (see some of the locksport challenges offered by TOOOL as an example.)
Study current attacks and develop technical countermethods.  For example, to counteract a Rolljam attack, you might consider building a 433 MHz jammer detector.  But that's only a defense against one type of attack.
Get new a car that uses a cellular connection to the internet and protects its communications via TLS, then use your phone to lock and unlock the doors.
Get a new car with a different security model built-in; like a Tesla that uses RFID cards and Bluetooth, instead of a remote keyfob.  But note that RFID tags use their own security that comes with its own weaknesses.


Nmap / Qualys say 3DES is available, but OpenSSL fails to connect Running a Qualys scan showed that the IP was vulnerable to a Sweet32 attack, here is the output:

TLSv1 WITH 64-BIT CBC CIPHERS IS SUPPORTED
DES-CBC3-SHA    RSA RSA SHA1    3DES(168)   MEDIUM
TLSv1.1 WITH 64-BIT CBC CIPHERS IS SUPPORTED
DES-CBC3-SHA    RSA RSA SHA1    3DES(168)   MEDIUM
TLSv1.2 WITH 64-BIT CBC CIPHERS IS SUPPORTED
DES-CBC3-SHA    RSA RSA SHA1    3DES(168)   MEDIUM

Then I ran nmap which output the following

443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Which seems to match the Qualys scan. But then I tried to confirm via OpenSSL running

openssl s_client -connect ipimscanning -tls1 -cipher 'DES-CBC3-SHA'

Which throws an error that seems to say this cipher is not available on the target

error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match

I can connect fine using another cipher for example

openssl s_client -connect ipimscanning -tls1 -cipher 'AES128-SHA'

The above runs fine and connects. Why might nmap and Qualys say that the cipher is available, but OpenSSL cannot connect?

That error means that the openssl tool could not find a cipher that matches "DES-CBC3-SHA" so it did not even attempt to connect. Your OpenSSL has been built without 3DES support (as has mine, OpenSSL 1.1.0g on Ubuntu 18.04).

The actual output when there's a mismatch looks like this:

$ openssl s_client -connect example.com:443 -cipher CHACHA20
CONNECTED(00000003)
140576084648384:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1399:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 128 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1550260584
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---


Why are CA's signing keys available on the internet I am not very knowledgeable about CA certificates, but I thought these things mainly said
"The public key for bank X is Y, and this is verified by CA Z".

Once you've bought this certificate, there is no need to be in touch with the CA, and thus they have no need to keep their generating computers connected to the internet, no?
Then why were hackers able to steal the private keys from Comodo and DigiNotar ?
(there must have been a good reason to keep those computers connected to the internet?)

The CA key should be well protected against physical attacks, because you do not want it to get stolen. It is an extremely valuable asset, since the corresponding public key has been embedded in widespread operating systems. So it must lie in a tamper resistant device (a Hardware Security Module), and that module should be in a bunker with guards.

On the other hand, it makes little sense to have a protected bunker if the employees just enter and exit it all day long. For a commercial CA which issues hundreds or more of certificates every day, the employees who handle the identity verification procedure and decide that the certificate should be issued must be, in practice, located "elsewhere". So now the device with the signature key is linked to the employees through some sort of network.

Physically private networks are extremely expensive, so everybody just uses "the Internet" and some sort of cryptographic protection for that link (e.g. SSL). So there you have it: the CA is "on the Internet" because it would be impractical (i.e. very expensive) to do otherwise.

Also, a CA should periodically publish Certificate Revocation Lists, that it signs with its private key. This also requires a regular network connection. You could do it with a daily/weekly manual transfer with a USB key, but human employees are not cheap, contrary to a crontab and an ethernet cable.

Good CA use a two-tier system with an offline root, which is used only once per year (this time by entering the bunker) to issue sub-CA certificates to the machines which actually do the common certificate signing.


How can I prevent XSS on a $_POST input? I already followed the suggestion here
and added:

/* Prevent XSS input */
$_GET   = filter_input_array(INPUT_GET, FILTER_SANITIZE_STRING);
$_POST  = filter_input_array(INPUT_POST, FILTER_SANITIZE_STRING);

to the top of my PHP file.
But my question is, is the way I use the $_POST on this required input secure?

if (empty($_POST['number']) || !isset($_POST['number'])) {
    $this->setStatusMessage($translator->translate('please enter your number.'));
    $this->setStatus(KDatabase::STATUS_FAILED);

    return false;
}else{
    $this->telefonnummer = $_POST['number'];
}

Don't think about protecting your inputs to prevent XSS - it should all be about output.

XSS, and other code injection vulnerabilities happen when data is not properly escaped or converted for the context in which it will be used.

How you do that depends on the output technology and context. As  AndrolGenhald mentioned in the comments, if you are outputting directly from PHP, without using a templating library, and you want to use a variable in the context of HTML code, then you should pass it through the  htmlspecialchars function. With other contexts and technologies the answer will be different. You need to find the correct way to escape data for each context.

If you can make sure you're always escaping data on output correctly, then you shouldn't use FILTER_SANITIZE_STRING. That irreversibly strips various things out of the string, rather than simply making them safe. On a well made website like StackExchange I'm free to submit the code <script>alert('XSS')</script>, and it doesn't get stripped, it just gets encoded so the browser safely displays it instead of executing it.

The code in your question doesn't include any output, so it can't itself be vulnerable to XSS. You need to show code that produces some output if you want to know if it does it safely.


Does PGP encrypt all messages or only that one send with PGP? If I encrypt my Email with PGP will all of my emails will be encrypted or only that ones that people send to me using my PGP key?

If I register on Facebook or Dropbox and they send me an email: "Activate your account" this email will be encrypted or not?

PGP only encrypts the emails you send out. Secondarily, you can decrypt PGP-encrypted emails if you have the sender's key.

Facebook and Dropbox do not send PGP-encrypted emails.


How should I encrypt an image if I want it to be maintained as an image? I have a task in which I need to encrypt an image, but the result also has to be a viewable image. My first thought when doing this was to extract the RGB values of each pixel, encrypt them, and create an image with the result. The problem is I can't find a cryptographically secure way to encrypt ints to ints with a given passphrase. Is there a better way to do it? Or is there a way to encrypt 32 bit values to result in 32 bit values?

I can't find a cryptographically secure way to encrypt ints to ints with a given passphrase

Most encryption algorithms, both symmetric and assymetric use integers. The problem is usually converting other datatypes to int.

If you were to encrypt it, and put it back as an image, it would look like this:

I think what you're looking for is steganography:

Whith this you can hide any file (images too) inside an image.
The image will still be viewable but hide data in small color offsets.

Here are some open source tools to do this.

http://sourceforge.net/projects/steghide/files/

http://sourceforge.net/projects/crypture/

http://sourceforge.net/projects/openstego/files/

But this is just the hiding part,
encrypting can be done on a unix system with GPG:

gpg --output doc.gpg --symmetric doc


What security technology do I need to protect my SSN database? I'm designing a web application. I need to make sure all my customer's SSN data is secure. Now I know HTTPS with SSL, I'm wondering what are its weaknesses? What else I need to provide a perfectly secure web interface? I'm going to host the server via Amazon EC2 or some other cloud service.

HTTPS is only one part of the puzzle - securing the link between webserver and customer's laptop - and to be honest, it is the simplest bit, as web servers and browsers pretty much do this right, however you will need to enforce SSL v3 and approved algorithms.

In addition you will need at a minimum:

authentication to your web application for customers (username/password, token)
session management
validation of input (see questions on SQLi and input validation)
protection of your database (possibly encryption)
controls defined for developers, admins and others who have access
an assessment of resilience - if your customer cannot connect to the EC2 instance, they are DoS'ed