When you redirect traffics to the host itself, the chain of concern in the filter table would be INPUT instead of FORWARD, so add the necessary ACCEPT rules to the former instead. Also the port of concern would be the new port as well:

iptables -t filter -A FORWARD -i $INTERNA -p udp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -i $INTERNA -p tcp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i $INTERNA -p tcp --dport 3128 -j ACCEPT
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


Where does StartSSL generate the cerificate, server or client-side?

I must admit I haven't tried StartSSL, but its FAQ suggests multiple mode of key generations for applying for a certificate. This may depend on the type of certificate.

The "Wizard" mode (FAQ#43) visibly generates the key pair on the server side. Although FAQ#44 assures you that they don't keep it, you're entitled to be suspicious. This isn't considered great practice, but this is probably for convenience.

Alternative methods normally used by CAs consist of generating a key pair on the user's machine and submitting only the public key as part of a Certificate Signing Request (CSR). A number of tools will let you save a CSR. This can also be done manually using OpenSSL, for example. In addition, a key-pair can also be generated in the browser (which will not send the private key out) and a CSR (or equivalent, e.g. SPKAC or CMRF).

The wording of some other questions is a bit confusing, but it suggests they can accept CSR or SPKAC requests.

FAQ#33 says "I created a private key instead of submitting my certificate request (CSR) for IIS server". Opposing creating a private key to submitting a CSR is a bit confusing, because you'd create a private key to create the CSR anyway. From the answer, it appears that you the private key has to be known at some stage by the StartSSL server ("Login to the StartSSL™ Control Panel and click on the "Tool Box" tab. Select "Create PFX File" and submit the encrypted private key, certificate and your password for the key."), which isn't great practice.

However, FAQ#51 "Can I submit a certificate request (CSR) for client certificates (S/MIME)?" seems to suggest it's also possible to do this without StartSSL needing to know the private key. ("The private key and certificate request are generated by either using the  tag (Firefox) or activeX control (Internet Explorer)".)
The limitations they impose in their answer is somewhat artificial. There's no reason in principle why one mode of application would be tied to a usage purpose for the resulting certificate.

The <keygen /> generates the private and public keys within Firefox and this sends a SPKAC request to the server (which contains the public key but not the private key, and is roughly equivalent to a CSR). The IE ActiveX Control can actually send CSR (in PKCS#10 format). Using either of these two in-browser modes, when you get the certificate back, it's imported against the generated private key, which you can then export together in a PKCS#12 (.p12/.pfx) bundle if you wish. That's why it's important to import the resulting certificate in the browser that you've used for the application. (FF doesn't show that it holds key-pairs that awaiting for a certificate, they only become visible in the options when you open the certificate back.)

EDIT:

Regarding one of your comments:

  Why again do people trust SSL more than OpenPGP?

Like many, you're confusing PKI and SSL/TLS.

I'm not a massive fan of the PKI model myself, because of its imperfections, but thinking that making everyone use a Web-of-Trust model (a la PGP) is sufficient to improve things is somewhat candid.

By using a WoT model, you may indeed have a less centralised system (which sounds good), but that makes the whole system far more complex, and much more difficult to think of, especially for users who "just want it to work". The difficulty mainly comes from the fact that each node in your WoT need to be trusted for two different things: (a) who they are and (b) their ability to verify who their next node is.

Trusting someone's identity is one thing, but trusting their ability (training and integrity) to do something opens a completely different dimension. If you consider that big CAs, whose job it is to verify others' identity, can sometimes have difficulties doing so, expecting that from all members of your WoT seems rather ambitious. Even if you wanted to restrict certain abilities to certain members, modelling those rules would itself be difficult.


How to check for security breach after a potential physical home intrusion

How can we go about verifying that no new software has been installed (Via live cd/usb etc) onto Windows beyond checking logs?

The easiest way is simply to go back to the last Restore Point. Go into the Start Menu, type Restore, then choose "create a restore point". From there, click on the System Restore... button and follow the prompts to go back to the last stable install.

  What measures should we take to make sure that the computer is safe to use?

Install Avast or your favorite anti-virus, and run a scan. Also install an anti-malware like malwarebytes and run a scan there. If there's some deeper infection that you suspect, you can't fix it; just buy a new system.

  Wiping the computer is not a desired option because of personal files.

System Restore won't affect personal files.

  BIOS settings show "Removable Device" is set as the first boot option, although this may have been priorly set by me or someone we trust.

This is typically default, and no cause for concern. Obviously, check your hardware for any USB drives. Some systems have extra internal USB headers that could have been tampered with. I know you said there's no undisturbed dust, but realistically, most of that dust is pretty hard to disturb, so you might want to just look inside for any extra USB drives inside.

Unless you're a government employee or a secret agent, etc, most likely, nobody's done any harm to this computer. A physical intrusion is typically used for immediate rewards; ID cards, social security cards, credit cards, etc. You should worry more about any financial institutions than the computer itself. As an additional security precaution, though, consider changing any passwords your sibling may use, especially bank accounts, emails, and any significant social media profiles.

Simply doing a malware and antivirus scan, plus changing any sensitive passwords, should be more than overkill for an average civilian.


Can I use /dev/urandom for generating cryptographic keys?

/dev/urandom is a good choice, but the getrandom system call would be ideal, using the default flags.

As for references, this article is not strictly speaking academic but it's a reasonably easy read, and cites a number of experts in support of its explanations.  I think this passage, which the article quotes from Daniel Bernstein, is well worth reproducing:

  Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

  we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but
  we can figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

  For a cryptographer this doesn't even pass the laugh test.

The article you've linked is more of a theoretical concern than a practical one.  What it means isn't that the Linux RNG design is bad strictly speaking, but that it's not optimal in a number of regards, which however only apply in a very narrow scenario: when an attacker has managed to see the RNG's state at some point in its execution but (a) is no longer able to see the newer states and (b) is able to influence its entropy input.  That's very specific—it lies at a very precise distance from normal operation (when the adversary hasn't seen the RNG state) and worst-case scenario (where the attacker has completely compromised the RNG and is able to see the state repeatedly).


Is the Android screen lock good enough to prevent access to an Android 8 device?

Regarding your given information it's kinda hard to answer your question. Since Android 7 File-based Encryption have been supported. It depends on the vendor of the phone if this is activated by default. I googled a bit about your phone (Huawei Mate 10 Lite) and haven't found official information about that. On reddit are some questions which state that this phone needs to use this type of encryption. So if I'm refering to this and the fact that you set a secure password on your phone it is safe to hand the phone over to a repairman.

But note:
If you hand it over, take care that you cannot see traces of your finger on the damaged display. If you see 4 touches at the position of the pinpad it won't be hard to guess your password. So clean the phone before you give it to them.


How is a ddos simulation any different from a real attack?

The relationship is one-way: the simulated DDoS is similar to a subset of possible DDoS. So if your system is killed by the simulated DDoS, then you have positively proven that the system does not resist well to DDoS in general. On the other hand, if your system keeps on operating while under your simulated attack, then you have not proved resistance against generic DDoS attacks, only resistance against DDoS attacks which match your simulation. It is still a useful test (and quite similar to load testing, as others have pointed out).

The general framework of a DDoS implies that the attacker musters way much more resources than you, under the guise of many distinct genuine network clients. By definition, you cannot, even for testing purposes, muster more resources than what you can muster (duh), so you cannot really simulate a full-fledged DDoS.


Is this sufficient to verify a website's domain?

Is this a sufficient check?

No, your check is flawed.

An attacker can bypass the validation via e.g.:

https://attacker.example/?https://www.trusted.com/

This URL resolves to the origin attacker.example, but satisfies url.includes('https://www.trusted.com/').

  If not, then how might I do it properly?

E.g. use URL.origin. If url is the URL string, you can do:

(new URL(url)).origin === "https://www.trusted.com"

In practice, this is also safe, but less expressive and easier to get wrong:

url.startsWith('https://www.trusted.com/')


Is the OpenPGP private key inherently password-protected?

It is possible to leave your PGP key unencrypted (no password), and thus if it were copied it could be used without a password. Encryption of your private key is inherent to the specification (RFC 4880 -- see "String-to-Key" sections), and anytime you're using software that asks for the passphrase for your private key, it is using that for actual decryption. Most modern versions of the software take pains to also avoid allowing the memory used for the unencryped key or passphrase to be swapped to disk.

So no, your private key cannot be used without knowledge or breakage of your password.


What is the recommended way to generate API tokens using Laravel framework?

laravel use php concepts and libraries.
so if we install any jwt libraries we can find out all of them use a configuration file for set expire date for jwt tokens ( for example 7 days. ) see this article
you as developer can configure it e.g 30 s. https://stackoverflow.com/a/41268134/308578
if you watch this video i definitely sure ,you can found out more about jwt token libraries functionality and their concepts . but this video about nodejs but concept is the same ....
any time to want you can refresh or generate tokens and pass it to your clients.
i think after this video you can understand more all you want
enjoy


Save decrypted pcap or decrypt on reading with rdpcap

You use airdecap to decrypt and save 802.11.


Acceptably secure within the realm of what?

You have described the basic flow for all bearer tokens. They who bear the token have the power. You do have a condition where you check if the token has been revoked, but that will mean the token is valid until they expire or are revoked. This is fundamentally the same as checking if the user is valid in the database, but you're replacing user with device + JWT. That's fine, but it's not much of a performance gain.

Other systems use two JWT's (or a JWT and an opaque token). The first JWT is your access token used mostly like you describe, but you don't check for revocation. This token is very short-lived -- maybe 20 min -> 1h, and then you have your refresh token which lives considerably longer. When your access token expires you send the refresh token and if the refresh token is still valid you issue a new access token. If the refresh token is expired you can force authentication again, or just issue a new access and refresh token.

The value here is that you only need to validate the refresh token against the database, and you only need to do that when the access token expires. When the user marks the refresh token as revoked then the refresh token doesn't get the attacker a new access token.

The trade off is that you don't query into the database as often, but the attacker can do whatever they want as long as the access token is valid. This is mitigated with using a very short lived token (its a game of odds). Whether this is an accepted risk is totally up to you. We don't dictate whether you should accept the risk. :)


CSRF by manipulating HTTP headers from client side using JavaScript

JavaScript from another domain cannot manipulate or read content from your domain, even in an IFrame, due to the Same Origin Policy. Therefore the attack scenario you describe is not a risk as this is not a vulnerability.

Bear in mind that Double Submit Cookies has other vulnerabilities. See this answer.

A way of circumventing CSRF protections is for an attacker to use Clickjacking instead. To prevent this make sure that your site cannot be framed using the X-FRAME-OPTIONS header and Content Security Policy's frame ancestors directive.


Is it safe to post dxdiag on the internet?

TLDR: It's probably fine, and MS meant it not to leak anything important.

It's worth stepping through this line by line, but it's too long. So let's leave out anything that's fairly innocent.

Essentially though, an attacker must work out what your system is (and this has no obvious Personally Identifying Information), and somehow find a specific driver of OS exploits. It's probably too much work to be worth it for most.

System Information: Mostly innocent. Machine name and exact OS version's there. If someone knew how to get to your system in the first place, and there was a specific issue with that version... maaaybe.
DxDiag Notes: Mostly innocent
DirectX Debug Levels: Nothing that seems to be problematic here. Mine gives no useful information.
Display Devices, sound devices, video capture devices, DirectInput devices, System Devices: Driver versions I guess. Driver versions are useful for troubleshooting, so its needed here. If someone knew how to get to your system in the first place, and there was a specific issue with that version of the driver, maaaybe
Disk & DVD/CD-ROM Drives: As above, and how much space you have used.
Preferred DirectShow Filters, Media Foundation Transforms,Media Foundation Enabled Hardware Categories,Media Foundation Byte Stream Handlers, Media Foundation Scheme Handlers, Preferred Media Foundation Transforms
Disabled Media Foundation Transforms
Disabled Media Sources: ALL TEH CODECS. Probably completely useless to anyone.
EVR Power Information: enhanced video renderer information. Nothing much here, I think.
Diagnostics: what's crashed or been troublesome. Looks like this, it's handy:

+++ WER7 +++:
Fault bucket 120429940662, type 4

Event Name: APPCRASH

Response: Not available

Cab Id: 0

Problem signature:

P1: pa.exe

P2: 0.0.0.0

P3: 5626c8a1

P4: KERNELBASE.dll

P5: 10.0.10586.162

P6: 56cd45b4

P7: e06d7363

P8: 0000000000071f28

P9:

P10:

On the whole? Not too likely.


What are the risks from letting users share their own calendars?

But the risk would be manageable by the individual users ...

"Would be" is very different from "will be". Users are also capable of choosing strong and unique passwords but they rarely do because it is inconvenient. Similarly it is likely that users will not properly take care of the risks with sharing calendars because it is too much effort.

  ... and the same info is available through other means.

It is very different if some competitor has fast access to lots of sensitive information about the activity of a company in one place instead of taking the time to dig through lots of information and correlate these. And, if the information is also easily available through other means then you might be doing something wrong. Restricting access to calendars is not the only thing one should do to protect such information.

  Hiding calendar information prevents somebody from sharing it with their spouse or other person that is considered trustable.

Hiding calendar information is different from hiding full calendars. It is possible to forward select entries to others. Some systems also allow to share just information about busy vs. free without sharing the details of the events.

  Are the risks from calendar sharing widely considered to be serious enough to cause the inconvenience that is inevitable?

Yes. At least in larger companies it is common that full access is restricted to anybody working in the company and maybe even limit access inside the company.


How was The Pirate Bay datacenter kept hidden?

The pirate bay used multiple proxies around the world. As soon as one got detected, they switched over to another one. They used preinstalled encrypted images that they deployed at numerous cloud providers around the world. In order to stay hidden, the servers used many different techniques.

All traffic between the proxies and the main servers was tunneled through vpn connections. If a proxy lost contact with the main servers for 8 hours, it shut itself down. A fully encrypted, completely shut down server is probably never going to be decrypted without a key, if done right. The standard police method of taking computers, by unplugging the power to avoid shutdown scripts from running, ment that the in-memory key was lost as well.

On top of the proxies, they used cloudflare to hide the location of their proxies from the general public. The pirate bay DNS records still point to cloudflare today. Cloudflare is one of the companies that takes privacy really serious, defending the lulzsec black-hat hacker group's website from big DDOS attacks in 2011. Since cloudflare has support of automatic failover, a proxy being taken offline isn't a problem at all. When you are starting to run low on proxies, just spawn twenty new ones on other cloud providers, add them to the list and call it a day.

If you cannot ever read the configuration from a siezed server, and there's at least two levels of ever changing proxies in-between, there's not much you can do to find out where the backend servers are.


Some scanners simply search for the injected string ("found" in this case) somewhere on the page, if "found" is in the search results, then it would classify it as a positive finding.

If the XSS string is being interpreted as a string in the search function (literally searching for the string <script>alert('Found')</script>, then you can chalk it up as a false positive - the scanner saw its own injected string in the resulting page.


Risks of using AJAX on an HTTPS domain from a page served over HTTP

You have an HTTP dashboard that loads API content over HTTPS. This implies that if a man-in-the-middle attacker observes someone requesting the dashboard, they can arbitrarily modify the response and inject their own content, e.g. in a way that will reveal all subsequent API requests by the modified dashboard page to the attacker.

An attacker could achieve this by injecting JS code that with each API request also sends the response to an attacker-controlled domain or possibly by rewriting the requests to the HTTPS API to plain HTTP.

  I don't know if this will affect any HTTPS calls that are made after the page has loaded in a user's browser.

After the HTTP site has loaded and only under the condition that the attacker cannot observe any plain HTTP requests afterwards (meaning the user never reloads the site), the attacker wouldn't have a chance to eavesdrop on any subsequent HTTPS requests to the API or modify any content.

(But they could trick the user into reloading the HTTP dashboard by blocking the HTTPS requests - making the user think there is a bug that could be fixed by reloading the site.)


Can a piece of malware/virus inject itself into an ISO

It is technically possible to write some malware that intercepts the ISO extraction process and then writes a boot sector to the media in order to run some malware before the normal boot sequence to hinder detection.

I do not know whether there are any current occurrences of this type of malware in the wild however. It is probably not worth worrying about unless you would be the target of such an attack because it is not a commonly used technique. Most viruses propagate because they use common attack vectors that are known to succeed on a large scale, and such an attack would be technically harder to achieve (both ISO interception and the installation of a bootloader to launch in memory persistence) so these things are unlikely outside of a targeted attack.


Payment device compliance of PCI v2 AND PCIv3

I'm going to assume that when you say PCI v2 and PCI v3 you mean the PCI PTS POI standard - ie the one for physical devices that include pin entry or are secure card readers. I’d personally be very surprised if a software upgrade changed the appropriate version number, because the hardware security profile changed between v2 and v3. The easiest way to check is on the PCI SSC website. All PTS devices are listed here:
https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices


Why is FREAK being presented as a brand-new vulnerability?

No. TLS_FALLBACK_SCSV was designed to prevent protocol degradation (from TLSv1 to SSLv3 for example), not cipher degradations.

To mitigate against cipher degradations, the server needs to stop offer export ciphers, or the client needs to stop accepting export ciphers.

TLS_FALLBACK_SCSV is designed to fix the vulnerability of downgrades in the protocol (regardless of cipher used), because SSLv3 and prior protocols, do have vulnerabilitys that can be used regardless of cipher.

Preventing export ciphers in a client is cumbersome, because the client must support any legacy ciphers aswell for backwards compatibility. But you could check in about:config if there is possibility to disable export ciphers.

If you however is running a server, its very possible to prevent the server from offering export ciphers at all, by reconfiguring it to never offer export ciphers in the SSL configuration. Then any cipher downgrade attacks cannot happen.

Note that you still need to support TLS_FALLBACK_SCSV, since a protocol downgrade can still break a "strong" cipher due to vulnerabilitys in the implementation.


Am I safe to see a thumbnail of a downloaded images on Ubuntu 14.04?

It depends on what you mean by safe.  Ubuntu has to parse and decode the image file to display it in a thumbnail.  So any potential exploit in the decoding code is exploitable when you preview the file.

So from a strict perspective, no you're not safe.  In practice, I don't believe there's any known exploits on ubuntu for image files.  Historically images tend to be low risk.

If you have reason to be suspicious of a file, turn off the preview feature as described:

https://askubuntu.com/questions/136024/how-to-stop-nautilus-from-creating-thumbnails-of-specific-file-types


How does a VPN help the internet security of a home user?

The assumptions here is that the VPN provider is running from a country that are one or more:

have more freedom than your own, especially if you live in oppressive or very conservative countries, your local internet provider or government may block content/site to materials that they do not want you to have access to (e.g. politically sensitive materials, or things they consider "morally inappropriate"),
doesn't have jurisdiction to physically arrest or harass you. Even if the country have Intel exchange agreement with your residence country, often multi jurisdictional police work are too much a hassle to follow through on smaller infringements,
if your local internet service provider is known to snoop into your internet usage or even sometimes alter content (often ads), and because of monopoly, you can't really switch to a different provider. Legal protection against such snooping may be weak or nonexistent in your country, or they may actually be the one requiring provider to do such snooping.
to bypass geoblocking of copyrighted materials, there are many cases where you can't even legally purchase a movies/show from your home country for any money, so you may prefer to use a VPN that runs from a country where you can access and purchase the material from a trustworthy overseas content provider, instead of from seedy underground services
If your country doesn't have strong net neutrality protection, your local internet provider may have business dealings that aren't in your best interest. For example, they may block or shape traffic from competing content providers or limit resolution because they want you to purchase their overpriced TV service.


How can I use nmap to distinguish between a normal linux machine and an android device?

I've used nmap extensively and while I've found it's in general pretty good at discovering the OS on server and desktop/laptop hardware it's pretty poor at detecting embedded and handheld kernels.

This is because quite frequently these systems are not listening on any ports, and it's the responses to TCP handshake process that gives the most OS detection information.

Without an open port all nmap has to work on is the response to closed ports and ICMP echo replies.


Heartbleed - Read only the next 64k and hyping the threat

The 64k block that gets returned is selected effectively at random, which seems like it would make it hard to find worthwhile data.  However, there are two factors that significantly increase the threat:

First, the attack won't return memory that was allocated during program start-up.  This means the area occupied by boring things like program code won't show up in attack results; likewise, the half of the address space reserved for the operating system won't be returned.

Second, because of how memory allocation is done, the 64k block will tend to come from recently-used memory.  For example, if a server handles a lot of login attempts, the memory is likely to have been used for a recent login, and could very well contain a username/password pair or two.  Good timing might get you memory used to set up the SSL connection, and you might be able to find an SSL private key in that.

A third point is that the attack can be performed quickly and repeatedly -- and is almost impossible to detect.  A home internet connection might be able to hit a server with tens of thousands of heartbeat requests per second.


One risk that can occur here is Cross-Site Request Forgery (CSRF).  Say you have an application running on your localhost which presents a web server for administration purposes.  If you allow localhost in a browser, when visiting a site controlled by the attacker, the attacker could request a URL such as

http://localhost/admin/do_some_action?delete=yes

which if valid for the site listening on that host could cause an inadvertent action to be taken.

Now this of course requires a vulnerable service to be listening on that port, so not everyone would be at risk here.  However what Microsoft have likely done is look at the trade-offs of allowing or disallowing this access and decided that for the majority use case there's more risk than benefit, so they've set this default, whilst providing a work-around if needed.


Does putting in quarentine attachments with two dots increase security in Outlook 2010?

Yes, but there is a difference. While "cute-kittens.gif.exe" can raise some eyebrows, since a GIF shouldn't be executable, I wouldn't say the same about .tar.gz files. To be more clear, .tar.gz should be considered as dangerous as .zip.

In fact, since any compressed archive coming from a Unix-like system is usually .tar.gz, a .tar.gz file could have a reasonable justification, such as a compressed archive of pictures, whereas I don't think a .gif.exe could be justified in any way. Much in the same way, a .txt.gz file could simply be a compressed text file, and should not be viewed as suspicious just because of its extension.

It is true that compressed archives (even .zip, .rar,etc.) can be used in order to complicate the AV scanning process, for example by sending a password-protected archive or by deploying a zip bomb, so putting in quarantine compressed files may be a good idea. However, this doesn't depend on the "double dot" extension, but simply on the fact that they are compressed files.

TL;DR Files with extension ".X.exe", where X is docx, pdf, gif, jpg,etc.  should always be blocked. Compressed archives having extension.tar.gz extension are no more dangerous than a zip archive. If Outlook only quarantines .tar.gz files, as opposed to zip, rar, and so on, this is wrong.


If someone has access to VPN and your computer, is there a point of using VPN?

I am going to interpret your question as meaning the attacker can see network traffic from your computer and the from the VPN endpoint.

It depends what you are protecting against.

Generally, the term VPN is used to refer to an encrypted communication channel across an open medium such as the Internet, so if you want to hide the information being communicated, then a VPN is a very good way to protect yourself. Encryption helps this information remain confidential.

If you want to hide the fact that you are communicating, then this won't necessarily help so much, as an attacker with the network visibility you describe can cross-reference requests and responses.

However, if the attacker actually has access to your computer - then you have far bigger problems, as all your communications and data can potentially be viewed, compromised or destroyed.


One website - two different SSL certificates: two different CA's

what stops an individual from purchasing a certificate and certifying a site they do not own?

Common methods of ownership validation are:

adding an DNS record
uploading a file to your web
sending and email to person in WHOIS
adding a meta tag to first page

  What stops me from registering that site xxx.com, with another CA?

Nothing. You are allowed to have multiple certificates for one domain from multiple CAs.


Vuln Web App which includes LDAP Injection?

It is better to learn from a real world vulnerability than one that was engineered.

Bugzilla can be configured to use LDAP for authentication and it was vulnerable to LDAP Injection.  This is ideal because LDAP authentication bypass is the archetypal attack.

In general I recommend searching the CVE database for these types of flaws and then finding the vulnerable version.  This shouldn't be too hard with open source projects, because they usually give you access to source control and there for every version of the application.


Giving all users a shared account is not something I would consider. You would not be able to know for certain which user did what on the system, multiple people will be sharing the same account concurrently... All in all, it's bound to get messy at some point.

Imagine if one of them loses their phone, and you are forced to lock everyone out when you find out, not to mention that whoever finds the phone can log in and do harm and you would have a hard time figuring what was done by that user.

I would prefer the first option. Configure each app manually before giving access to employees, save and encrypt the key pair, or the password on the device and let them choose a password for unlocking application access. This way if a phone gets lost or stolen, you can simply de-authorize the affected key / account.


Is mosh now recommended by the security experts? (2014)

This used to appear in their FAQ:
Q: Has your secure datagram protocol been audited by experts?
A: No. Mosh is actively used and has been read over by security-minded crypto nerds who think its design is reasonable, but any novel datagram protocol is going to have to prove itself, and SSP is no exception. We use the reference implementations of AES-128 and OCB, and we welcome your eyes on the code. We think the radical simplicity of the design is an advantage, but of course others have thought that and have been wrong.


Using the user's password hash as their refresh token (with the password hash in their JWT)?

Well, you've converted your short-lived access token into a refresh token because you're storing the refresh token in the access token. That pretty much defeats the purpose of using an access token.

It's also usually unwise to send the password hash to the client because these things tend to get leaked through bugs or overzealous logging and that makes it possible to brute force the password offline (though you already have access to the client, so...). It also means you can't revoke the refresh without forcing a password change. That might be fine, but it's also potentially annoying for the user. The refresh should have an expiration too.

In general you should never reuse secrets for things that weren't their intended purpose. You should use a dedicated value for the refresh token, whether its a pointer to some value in the database, or a token itself signed by a secret key plus expiration. And you shouldn't store the refresh token in the access token.

All of that adds up to the usual recommendation of: don't roll your own. Find a library or service that already does this for you. There's plenty of them out there that are free or cheap, and many have excellent track records for security.


Could it be insecure to suggest linking accounts to other identity providers based on their email address?

Only if you can validate that it is truly Bob logging in. Otherwise, you're handing a ton of data and power over to fake Bob.

A better step would be "Hey, is this you? Login in with Twitter/your other creds to merge your account." That way, an attacker would have to know Twitter creds AND G+ creds to roll the accounts together. If they do, then poor Bob is screwed either way, and if it really is Bob, he can just go "oh, that's right!" and present the Twitter credentials.

Of course, this presents a usability and UI challenge, but I have the UX skills of a pebble.


Does this mean that all network traffic (when not connected to the company wifi) was being monitored?

The traffic was likely monitored while you were in the company since your traffic there went over the corporate firewall. While you are outside the company your traffic usually goes not over this corporate firewall (unless you use a VPN into the company) so they could not monitor you.

In theory the company could use this certificate if they manage to control your traffic. This could be for example the case if you use the companies DNS server or if they explicitly attack your network. But, while possible, this is unlikely as long as the company you work for has proper ethics and has no real reason to monitor you after you've left the company.

In any case it is good that you've deleted the companies root certificate. And if you did not get any errors while visiting HTTPS site after you've deleted the certificate it is very likely that they don't monitor you now and probably did not monitor you before after you've left the company.


Is Tomcat vulnerable to "Ghostcat" (CVE-2020-1938) via mod_proxy_ajp?

It is unlikely that this vulnerability could be triggered via mod_proxy_ajp.  It can be generated by setting the relevant AJP attribute as an environment variable with AJP_ prefix on Apache.  As below.

SetEnvIf Request_URI .* AJP_javax.servlet.include.path_info=WEB-INF/web.xml


Does allowing unsafe-inline script defeat the purpose of CSP?

Won't whitelisting unsafe-inline and unsafe-eval kind of defeat the whole CSP?

Yes. A tight CSP will make it harder to exploit XSS by restricting the scripts that can be executed. Using unsafe-inline and unsafe-eval allow to run any script. This is also why they are prefixed by unsafe-, to discourage you from using them in the CSP.

Of course the data: protocol also makes it possible to bypass the CSP, since you can encode any script as data: URL.

  If 'unsafe-inline' is allowed or whitelisted as above, can someone call a JavaScript from an external website

You could retrieve the script contents and run them from within JavaScript. Including it with <script src="www.xxxxxx.com/bad.js"> doesn't work but since you can run JavaScript anyway there are other ways to run external script.


How do I organize my input for a buffer overflow?

The goal here is to make eip point to your shellcode. There are many ways to do that. The first thing would be to check if your shellcode is placed in a register. If that happens then you can perform a ret2reg (return to register) by finding a gadget that will let you return to that register (like call reg etc...). Another way would be to use a nopsled - but that is not that stable. In that case your payload could be like:

nops + shellcode + (1040 -len(nops+shellcode))*"A" + pack32(a_nop_address)

Have in mind though, that the "a_nop_address" from the above payload changes inside gdb and will not be stable in case aslr is enabled.  All the above ways assume that your stack is executable of course. Another way is also to use a shell variable that will contain your shellcode and then make eip point to that address. Finally, there are also more advanced methods, like ret2libc, ret2plt, ROP etc..., that do not even use a shellcode to pop a shell and can also help to bypass some security mitigations like aslr and non-executable stack.


False 'Security alert' from Google - every login generates mails from 'no-reply@accounts.google.com'

I guess I receive those mails because I use a VPN (always same public IP) and some privacy plugins in Firefox.

Yes, this is likely the reason. You use these plugins in order to prevent that the other side can detect that you are the same user on the same device as the previous time. And that's exactly what the mail from Google says: it detected a login from a new device since it could not detect your device as the one you've used before.

That's actually a common compromise one has to take: if privacy or security goes up the usability often goes down. In this case a useful security feature against misuse of your account (security up) conflicted with a useful privacy feature (privacy up) which caused the usability to go down.


How are one-time password generators like Google Authenticator different from having two passwords?

Passwords are revealed every time you use them: if you have two passwords and you type them into a fraudulent web form, they are both stolen.

The shared secret can't be calculated from a single OTP (or even from a set of them**), so a stolen OTP is only valid for limited time. The shared secret is never transferred during the authentication, so stealing it requires a different attack vector: access to the device where it is kept or copying it (e.g. its QR code) during the initialization.

** Calculating shared secrets backwards would be very impractical, as it's a one-way algorithm. Also, the minimum key length is 128 bits and the algorithm produces only 6 numbers i.e. ~20 bit OTP. This means for every OTP there would be oceans of potential shared secrets, and finding even a single match would only be possible with brute force i.e. calculating 2^128 hashes for every 30 seconds and ruling out every OTP that didn't match.


Is it possible to run Meterpreter command in background

Here are three ideas to consider:

Use bgrun with search_dwld.rb
Use file_collector.rb
Create your own script

bgrun

The best solution I can find for this is to use the command bgrun. As the Metasploit script states,

  "bgrun" => "Executes a meterpreter script as a background thread"

Bgrun executes a script in a background thread, however the search command can't be used with bgrun. The closest script I can find to the search command is search_dwld. Search_dwld works in a similar way to search and also downloads the files that have been found.

The usage for search_dwld is as follows:

  search_dwld -- recursively search for and download files matching a
  given pattern

  USAGE: run search_dwld [base directory] [filter] [pattern]

  filter can be a defined pattern or 'free', in which case pattern must
  be given

  Defined patterns:

  $filters.keys.sort.collect{|k|"\t#{k}"}.join("\n")

  Examples:   run search_dwld

  => recursively look for (MS|Open)Office in C:\

  run search_dwld %USERPROFILE% win9x

  => recursively look for *.PWL files in the user home directory

  run search_dwld E:\\ free '.(jpg|png|gif)$'

  => recursively look for pictures in the E: drive

You can use search_dwld with bgrun like this:

bgrun search_dwld

File Collector

Another option is the file_collector script. As the link above states,

  Meterpreter Script for searching and downloading files that match a
  specific pattern. First save files to a file, edit and use that same
  file to download the choosen files.

file_collector is a three part process. First we create the file list, then we remove any files we don't want from the list, then we execute the download process. Here is a guide on how to use file_collector.

You can also use file_collector with bgrun as stated earlier with search_dwld:

bgrun file_collector

Create script

Another alternative is to make your own script in Ruby which searches for files.

bgrun searchScript.rb

This could actually be a good solution as you can make the script fit your exact needs.


my server got hacked and I only got to find the cronjob command

From what you said, it's hard to tell if the server was hacked via you web app/site, or via some outdated software, or some other way, but some things you could try:

Check your apache/nginx logs and try to find suspicious requests.
Check versions of server software (web server, perl, php...) and look for outdated versions.
Do a portscan with nmap and look for ports that are open but should not be.
Do a quick scan with nikto or some other webapp security scanner. Try wpscan if you are using wordpress.
Keep monitoring outbound connections and look for suspicious activity.
Change your passwords.
Ask/pay somebody to assess the security of your web app.

But basically only the log files could pinpoint the root cause. The other methods can identify vulnerabilities, but you can not tell if those were used by the attacker in this case.


yes definitely, fuzzer just helps you to find a potentially vulnerable code. It can be a coding error but not a security issue. Fuzzing is also difficult, you need to come up with good seed test cases and then you can use tools like AFL to mutate them.

Once a crash is found, you can look into it and see if it is a security issue. And then you will go into a whole different domain - exploit development.

Operating System has a lot of protection mechanism by default nowadays and it makes exploit development much harder than before.

Exploit development is turning a bug into an arbitrary code execution and allows the attacker to hijack the privilege of the running process.


WPS is a quick-config system that allows you to connect to a router without doing any configuration on the client side. It works by exchanging a pin code that acts as a temporary key, in order to transmit configuration details to the client. Unfortunately, the key is short, and easily brute-forced. The solution is to turn off WPS on your router, which you have done.

As for which method of encryption to use, WPA2-PSK is fine. So far the only attacks against it revolve around brute-forcing weak passwords, so if you're using a strong password then you should be alright.

The older WPA (WPA1, if you will) has problems that could allow an attacker to break into your WiFi by sending special probes, leading to information disclosure that can be leveraged via a cryptanalytic attack. WEP suffers from similar issues, but is much worse - in general WEP is considered to be about the same as no password at all, in the face of an attacker that knows how to perform basic wireless attacks.

Mixed mode means that both WPA and WPA2 are available, and the client can choose which to use. I'm not sure of the specifics, but I'd guarantee that this is less secure than just running WPA. I think in order to attack it there must be at least one authenticated client attached via WPA, but don't quote me on that one. The reason this mode exists is to provide compatibility with older devices. For example, a stock firmware Sony PSP doesn't support WPA2.

WPA-802.1x is another name for WPA-Enterprise, which involves running a RADIUS server inside your network to federate login requests. This uses Extensible Authentication Protocol (EAP) for the authentication. The primary benefits of RADIUS-based wireless security are that you can choose different credential types for authentication (i.e. you don't just have one shared key), and that you can prevent brute-forcing of logins. This is a more complex setup, though, and isn't well-suited to home use.

The last thing to consider is the encryption scheme. The two standards are Temporal Key Integrity Protocol (TKIP) and Counter Cipher Mode Protocol (CCMP). The first is based on RC4, and is used by WPA. The second is based on AES, and is much stronger than TKIP, and is the default for WPA2.


Monitor with two simultaneous, seperate inputs: can an OS read from both inputs?

While there isn't a way to do this as you've asked the question, there is a simple way to do it.

If I'm correctly interpreting what you're after here, you have a display connected to computer A, receiving a signal from it. You want to connect up a cable from computer B to the same display and see what is shown on the display from computer A. No, this isn't the way displays generally work, at least not without some fairly heavy customization.

However...

This is actually a fairly common ask for people that work with video. What we need to do it split the video signal coming from computer A before it gets to the display so we can get a copy of it on computer B. Easy peasy.

In between computer A and the display, we put a video splitter. One side of the splitter feeds the display as usual, the other side goes to a video capture card in computer B and we capture any video that we care to.

Additionally, building a splitter into a display would not be an onerous task. We'd likely want an older display, so there was a little space in the housing to work with, but it could be done.

On the positive side

This would be very difficult to detect without physically eyeballing the hardware
Its a relatively simple setup that we can put together with off the shelf components and software
Gaining access to log on to the target system itself would not be required, as all the components on that side are hardware

On the negative side

Visually inspecting the hardware would turn this up almost immediately, unless we buried the hardware in the display housing -- even then there would be an extra cable leading to another (extra?) system nearby
Running video captures for any period of time would result in huge output files -- you couldn't reasonably leave it on all the time

More than likely, you would be better served with something like a keystroke logger, presuming you could get on the system in question.


If the domains were the same, so the cookies were set on http://example.com/home/, and didn't have HTTP Only set, but there was an XSS vulnerability in http://example.com/vulnerable/, then the cookies can be accessed by the attacker - they can inject an iframe into the page, and use a script resembling document.getElementsByTagName("iframe")[0].contentDocument.cookie to access the cookies.

If the domains are different, as they appear to be in your question, then no, accessing the cookies isn't possible. All Access-Control-Allow-Credentials: true  does is tells the browser that it's OK to include credentials (cookies & HTTP Basic Auth) in the request - it doesn't expose those credentials to the requester (unless the website is for some reason including the details of the cookies in the response, which there are very few good reasons to do).

However, being able to access the actual value of the cookie is not necessary to be able to exploit it. The attacker is make authenticated requests as the user, and they are able to bypass any CSRF (Cross Site Request Forgery) protections by reading the CSRF token from the HTML document that was returned from the first request. This means that, provided that all endpoints return the relevant CORS headers (including Access-Control-Allow-Methods if some endpoints require POST rather than GET), the attacker can make the same requests via AJAX as they would have been able to on their own computer with access to the session cookie.


How to deal with a hacked laptop that's being remotely monitored

You are probably infected by a trojan. The first thing you should do is to change all your personal passwords (mail, facebook, gmail, etc) from another machine !

You can use the terminal to see what are the established connections :

netstat -anp --tcp --udp | grep LISTEN

See what are the processes loaded on boot and eliminate the useless ones.
You can use Wireshark to monitor the ingoing/outgoing traffic.

You can install Clamav :

sudo apt-get install clamav

and scan your hole system :

clamscan -r --remove /


Is the DNS service you are probing over TCP or UDP? There is a match line that looks appropriate (line 8836 in the latest SVN version), but it is only matched for TCP ports. Also, the fingerprint was added on February 4, 2012, so if you are using a version earlier than 5.61TEST5, you will not detect this service properly.

Nmap's service detection database is built from user submissions. If you have a service that is not being detected correctly, make sure your Nmap is up-to-date and  re-run the version scan with these arguments:

nmap -v -sV --version-all -p 53 example.com

and follow the instructions for submitting the fingerprint.


Unable to get rid of Sality on my Dropbox

You're not doomed, everything is gonna be okay.

Pause Dropbox sync on all of the devices associated with this account.
Turn off all of the devices that have Dropbox installed and associated with that account, and any other device that you know/suspect they're infected.
Now that you know your files are okay on Dropbox, nuke all of the systems you've just turned off.
On a machine that you 99.9% trust its integrity, install the Anti-Virus product capable of detecting/cleaning Sality out of executable files.
On that machine, install Dropbox and associate it with your account. Watch as your Anti-Virus detect/clean the virus from the files.
If there were no infections, you're done. If there were infections and the Anti-Virus wasn't able to clean them, wait until all the files are synced and then reboot in safe mode and use Win32/Sality Remover (from AVG) and  SalityKiller (from Kaspersky) to do a final sweeping.

A coupe of notes:

Infected files on your Dropbox will not magically infect your new clean system unless you run them somehow.
If you have the option, it's better to restore all your files to a previous version using Dropbox website instead of syncing and cleaning. (it all depends on the age of your infection and whether you have Dropbox Packrat activated)


Can SSL certificate (domain verification) process be eliminated?

I dont have to pay and wait for my certificate.

You don't need to do this currently. You can get free certificates in no time and fully automated from Let's Encrypt.

Browsers dont need to trust CAs

While browsers don't need to trust public CA directly in your proposal (which is essentially DANE), browsers still need some secure way to retrieve the public key. This can not be done with plain DNS since it provides no protection against spoofing and modifying the keys in transit. These protections are offered by DNSSec though. But DNSSec again involves some kind of trust hierarchy:  the local DNS resolver somehow must be able to verify the DNS servers response - which is again done using trust chains based on locally stored and trusted keys.
Trust relationships cannot just emerge out of thin air. There need to be some initial trust already which can be used as the anchor for building trust chains. This is true for PKI as used in the CA system as it is true for DNSSec as it is true for a web-of-trust model like in PGP. And it is true in "real life" too: one should not trust others just because they say so.


SSL replay attack when client/server random is missing

If the server uses the same nonce (called "server_random" in the SSL/TLS specification) and the same session ID than for a previous handshake, then an attacker can send the exact same packets than what the client sent during that previous session, and the server will accept the whole thing. At least if the server uses a RSA key exchange cipher suite (which is the most common case).

This can easily be seen by following how the various cryptographic elements are computed. The ClientKeyExchange message contains the pre-master-secret, encrypted with the server public key; that packet can be replayed and is still a properly encrypted version of the same pre-master-secret. The encryption and MAC keys are then derived from the pre-master-secret, the client_random and the server_random, through the SSL/TLS "PRF" which is deterministic. Thus, if the randoms are unchanged (i.e. if the server uses the same server_random than previously, and the attacker sends the same ClientHello message than during the previous session) and the pre-master-secret is also unchanged, then the server will infer the same symmetric keys and will thus accept the captured encrypted packets as being genuine.

The attacker doing the replay would not gain any extra insight as to what the application data could look like; the attack is not a decrypting attack. But from the server point of view, this would look like a second genuine, voluntary connection. For a SSL connection used for a HTTPS POST request for a credit card payment, this would mean a double payment.

Fortunately, it takes incompetence of non-standard magnitude to achieve a SSL server which always uses the same server random and the same session ID. I am not saying it never happens; only that it happens rarely. Notably, the TLS specification insists on the idea that the first four bytes of the client_random and the server_random should encode the current date and time, with a 1 second accuracy: if honored, even with a badly skewed clock, this alone ensures that a server with a badly flawed RNG will still use a distinct server_random after one second.


Is using multiple instances of a browser-PRNG to seed another PRNG more secure?

The Math.random() function in a browser's Javascript engine is not cryptographically secure.

That is, it does not draw from a truly random source of bytes, and it follows a predictable pattern, even if most people would be unable to recognize that pattern.

Simply using one semi-predictable sequences of numbers to set up a different semi-predictable sequence of numbers is not enough to meaningfully increase security.

Rather, if you need security, use window.crypto.getRandomValues() instead.


Why do several bug bounties ignore user enumeration?

Because they are already aware of the issue. This is evident of them making a mention on the exclusion list. Not mentioning it would likely lead to a lot of users pointing it out.

And since they are aware you might be wondering why they won't fix it. There really isn't a way to prevent it. If they restrict an email to one sign up they will have to inform the user why they cannot complete their registration if it has already been used. Or if a username is already selected, they would again have to inform them in an user friendly way why they cannot. So instead of taking out enumeration completely they will have to limit attempts, include CAPTCHA, or implement another plan to prevent abuse.

So when you have a known bug with no ability or intentions to fix it there really isn't any benefit to the company to pay out a bounty or receive reports on it.


Is generating a random salt for every password-hash but not saving the salt good/bad?

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

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

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

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


Can wireless (wifi, blutooth..) be attacked even when not connected?

Most modern OSes have services that are responsible for parsing data received by the wireless interfaces, and if the code responsible for that is vulnerable your machine could be compromised.

The only way to be safe is to tell the OS to completely disable the interfaces or at the very least ignore data received by them (on Linux for example you could kill the wpa_supplicant process). This is made more complicated by some OSes as for example Google, in an attempt to violate everyone's privacy even more, has added this "always-on Wi-Fi feature" to Android where the device will scan for networks (and be vulnerable as a result) even when the Wi-Fi is turned off, in an attempt to improve location services.

A fail-safe way to protect your machine no matter what the OS has to say is to disable the wireless interfaces using the hardware switches - that would prevent the radio hardware from working unless it was specifically designed to ignore the hardware switch but we're not there just yet.


How does ransomware get the permissions to encrypt your disk?

Ransomware doesn't get root/admin permissions, because it does not need to.

It does not encrypt the disk or files protected by the operating system (executables, configuration, credentials), it encrypts files created and stored by the users (data); and all it requires to do so, is the same level of access as the users themselves.

Just like a user would create a password-protected zip and delete the original file, so does ransomware (except, it keeps the password in secret and makes sure the original file is really inaccessible).

That's the whole reason why ransomware is so successful, it encrypts what is the most valuable for users and companies: their work.


Is there any point in using 'strict-dynamic' in an AngularJS 1.x application?

There is a bit of a fundamental security issue here based on the fact that an attacker can inject an Angular expression.  The Angular project itself has actually stated that the sandbox is not actually a security mechanism, despite the name, and removed it in newer versions to avoid this confusion:

http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html

In the case you are talking about, I would probably characterize this as working as intended, but not necessarily expected.  CSP is protecting the script elements to ensure that only trusted ones are executed, but Angular (your trusted script) is being coerced into 'interpreting' the expression in a CSP-compliant way (if you're using ng-csp) that yields the equivalent of script execution.


Is URL redirection in PHP safe if I use ../../ as a prefix?

You should never allow redirection to a relative path that can be manipulated on the client side. As you say, it's dangerous as it potentially allows access to files outside of your webroot. A better approach is to "tag" or name the target pages and redirect to them inside your code.

For example, when a user triggers a form, let it post redirpage with a certain value, like dashboard to redirect a user to a dashboard page. Then in your code, just check for a supported page name:

switch ($_POST['redirpage']) {
    case 'dashboard':
       header('Location: http://www.example.com/dashboard/');
       break;
    case 'account':
       header('Location: http://www.example.com/account/');
       break;
    default:
        // This fallback will be triggered when an "unknown" target page is set
        header('Location: http://www.example.com/');
}

That way, you control what redirects can be done and where they end up.


Is it possible my Computer is part of a DDoS network, is there a way to tell?

Yes, you can look for certain things to know whether your computer is being used as a botnet:

Look for unnecessary outgoing connections from your PC, using various windows or Linux or MAC(whichever you are using) tools.
Unnecessary programs running in your computer. Check the list of programs running currently, you may find something surprising maybe something you never started.
Lookout for sudden increase in outgoing traffic, Monitor outgoing traffic(graphs preferably) and check if you see spikes in them. Check their timestamps, are they regular and during same timestamps everyday?
And At last keep your computer protected so that no incoming connections can be made, and a good antivirus and antimalware is installed so that your computer can be protected from getting infected.

But as they say, You can never be too careful. You can just hope for the best :)


According to RFC 5246, are nonces in TLS useless (in terms of security) and if yes, why aren't they only random data?

Nonces do not require secrecy. The virtue of a nonce is to occur only once, not to be unknown to outsiders. The fact that the client random and server random are sent as cleartext does not prevent them from being "nonce".

The actual "nonce" is the concatenation of the client and server random. This is explicit in several places, especially in section 6.3 of RFC 5246, which deals with key computations: the symmetric keys used for encryption and MAC of application data are derived from a combination of the "master secret" and the concatenation of both randoms:

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +
                  SecurityParameters.client_random);

The two random values will also occur in the computations for the CertificateVerify and Finished messages, since both use a hash value computed over all the previous handshake messages, which includes the two "hello" messages and the random values they contain.

So the client random protects itself by sending a new client_random: whatever happens on the wire, the client will use the random value it sent for key computations. Similarly, the server protects itself with its server_random. To see how the protection works, consider a replay attack: the attacker observed a handshake between a client and a server, and then wishes to replay the same handshake with the server, thereby impersonating the client. The attacker observed this:

ClientHello (ch1)            --->
                             <---        ServerHello (sh1)
                                         Certificate (c1)
                                         ServerHelloDone (shd1)
ClientKeyExchange (cke1)     --->
ChangeCipherSpec
Finished (cf1)
                             <---        ChangeCipherSpec
                                         Finished (sf1)

The attacker then connects to the server, and sends an exact copy of the ClientHello (ch1). The server, however, responds with a distinct ServerHello (let's call it sh2): that ServerHello is very similar to the one used previously (sh1), but with a new server_random value. The attacker can then proceed with the handshake, but things will fall apart when the attacker sends the Finished message cf1: that message should contain a hash derived from all previous handshake messages, and be encrypted with keys derived from the master secret (that the attacker does not know, he merely "replays") and from both client and server randoms. For both computations, the server expects the Finished contents and the keys for encryption to have been derived using the random from the ClientHello and from its own ServerHello (i.e. here the "sh2" message). The "cf1" message won't match, since it was computed with hashes and keys from the initial handshake, with the randoms from ch1 and sh1, not sh2.

The recorded packets cannot be all replayed by the attacker because, by definition, the attacker replays only half of the conversation. When the attacker tries to impersonate the client, he can send all the packets on behalf of the client, but must work with what the genuine server responds (if the attacker impersonates both client and server, then he can do a "perfect replay", but he is actually talking to himself only, so this is considered a mental illness, not an attack). The server_random thus enforces a divergence which thwarts the replay attack.

(A similar case can be made with an attacker trying to impersonate the server when talking to a genuine client: the client_random protects the client against that replay attack.)

Alternative description: the client and server actually do verify nonces. They do so implicitly when they compute the symmetric keys, and check the contents of the received Finished messages. The client won't be content with a received Finished message from the server unless that message was computed and then encrypted using (among other values) the client_random that the client just sent, and none other (and similarly for the server).

The client and server "randoms" need not actually be random, although it is advisable. As explained above, the real value in the client and server random values is that they are distinct from previous values, for each handshake. They are public values, and there would not be any serious issue if they were predictable. Indeed, even if the attacker can predict the exact values of the client_random and/or server_random that will be used by given clients and servers, this won't help him running his replay attack: to succeed at replaying a handshake, the attacker must not simply know the client and server randoms; he must arrange for both client and server to reuse the same randoms as in the previous handshake which is replayed. Since the attacker impersonates only one at a time, he cannot enforce such reuse.

You may note that the said 32-byte randoms actually begin with 4 non-random bytes: these bytes encode the current date and time (number of seconds since a conventional instant). The purpose of these bytes is to try to ensure this non-reuse policy even for implementations with so terribly dysfunctional PRNG that they reuse previous random values. However, if the client has no good random source, this may have impacts on the security of the ClientKeyExchange and the master secret, especially with RSA-based key exchange (as is commonplace).


Why would Comodo SSL certs have two intermediate CAs (chain length 4)?

In many cases, the intermediate certs do mean something. Sometimes it mean the Insurance level (how much the signer will pay you in the event of a fraudulent verification) or it can mean the validation level (only domain verified, or full verified with Company details and Everything).

In this case, Comodo isnt even the top signer. Instead its a Company called UserTrust ( http://www.usertrust.com ). The Company is apparently owned by Comodo, which might tell that Comodo sub-licenses its certificates to other CA's so those CA's dont want "Comodo" as their top certs.
Now we have travelled 2 steps down the chain.

The third certificate, in Comodo's case, tells the verification level. For the SSL cert used on Comodo's own website, that intermediate certificate tells that the site certificate is a "EV Green Adress bar" certificate. The fourth certificate is the site certificate itself.


Can Machine Learning be utilized to identify and track IP Spoofing?

AI is not needed at all to identify IP spoofing, and the solution is trivial. It only needs the ISP to employ Egress Filtering on its side, and no client of him will be able to spoof any IP belonging to another ISP. Every ISP does this, and no spoofing exists anymore.
If Avocado Networks have the 123.123.123.0/24 block, and employs Egress Filtering, if any of its customers send a packet with a origin host 124.123.122.121, for example, the filter will detect a packet coming from an external network and drop it. The misbehaving client would only be able to spoof packets from the Avocado Networks block, and Avocado would find that client pretty fast.
Even if the "last mile" ISP does not employ it, the upstream ISP could, and alert Avocado Networks for IP spoofing coming from their networks, and threaten to throttle their connections until the spoofing ends. Avocado would have a big incentive to do so.
And IP spoofing on a TCP connection is possible on paper, but impossible in practice. SYN flooding is possible, but establishing a connection is not. UDP is easier, because there's no connection established - you just fire packets down the line. And Egress Filtering solves both IP spoofing over TCP and over UDP.


Why do browsers allow JavaScript of external web pages to connect to localhost?

Well, localhost itself is just a hostname, other hostnames could be used similarly be setting up an A record for 127.0.0.1. The real potential problem is that browsers can be manipulated to load content from the local network, like 127.0.0.1 (localhost), 192.168.1.1 (routers), etc.

Browsers do have a feature in place to globally limit such access across hosts, called Same-Origin Policy, however CSRF attacks against poorly designed systems are still possible.

Assuming the application developers are competent enough to not blindly assume data being sent is safe, and validate it properly, they should be fine. The real problem is developers failing to understand such basic web security are all too common. For this reason we have recently seen a surge in attacks against people's routers, where CSRF attacks can reconfigure the router without any user interaction, because it blindly assumes any local traffic is safe.

As for out-right blocking local network requests from non-local pages in the browser, I'm not aware of any browsers presently doing this, but it is something NoScript's ABE feature does by default. I've never noticed any real downsides to using it, so I can't really speculate on why browsers do not already do this.


As far as I can tell, the question is:

  They are practically unguessable, right?

The answer is a very strong it depends on the kind of attack you're worried about. Also, in the best case, what you're doing is equally as strong as using a password manager's randomly generated passwords, but almost certainly more effort, right?

@RoyceWilliams' answer pretty much hits the nail on the head:

  Generally speaking, if your method becomes weaker once it is known, you're doing it wrong.

Let's break this down a little farther. There are two types of password brute-force attacks you need to worry about:

Drive-by attacks

Aka "opportunistic". Here the attacker is looking for low-hanging fruit: they are attacking all users of the system in parallel, either looking for a single entry-point into the system (in which case any user will do), or they are looking to compromise as many accounts as they can with minimal effort.

They are unlikely to try any sort of "algorithmically-generated" lists, because they can get what they want simply by trying the 100,000 most common passwords based on this year's breaches. As long as your password is not on one of those "Top X Most Common Passwords" lists, you're pretty much immune already; you really don't need to go the extra effort.

Targeted attacks

Here you, and you specifically, have been selected as a target. Maybe there is data on your account that is of value to their employer, maybe you work for your company's IT help desk and sending a phishing email from your account is more likely to succeed. Whatever the reason, you specifically are being studied.

They will find your social media posts. They will find your post on this site. They will pull up all passwords of yours from previous breaches to study how you invent your passwords. They will write software to generate guess-lists based on everything they know about you. If they know that you like to use mathematical constants, or quotes from Tolkien, or wtv, they will build the appropriate guess lists.

Against a targeted attack, @RoyceWilliams' answer referencing Kerckhoffs's principle is relevant: your scheme needs to be secure even if the attacker knows what the scheme is. You may be clever enough to invent something that passes this test, but I'd bet that whatever you invent will be more effort than just using a password manager with 32-char random passwords. So do that.

These two attack models are meant to be a framework for thinking about the threat landscape, not an exhaustive list of things attackers will do. As @Ben points out in comments, there is a sliding scale in between these two that has some characteristics of Drive-by, and some characteristics of Targeted. Where you put your comfort level is your choice; although if you're considering this at all then, for the minimal extra effort, you might as well go all the way to the top and use a password manager.


They're suitable for different use cases. Assuming you're using a well-tested implementation written by somebody who knows what they're doing (so, probably not something you wrote yourself or pulled off some random person's GitHub), they're both quite secure, although the threat models are a little different. Also, HMACs are generally computationally cheaper.

HMACs are only usable when you have complete trust in both the party certifying the message (usually the author), and the party verifying the message's authenticity. Complete trust is required because the ability to verify an HMAC also means having the ability to forge one. It also only works when you have a secure way to exchange the shared key.

Signatures are used when the party verifying the authenticity is not fully trusted by the certifying party, or when there's no way to securely exchange keys. It's usually more computationally expensive and requires storing/transmitting more data, so it's usually not used unless needed.

HMAC key leakage is mostly a problem when "fully trusted" is a little fuzzy. For example, you might trust a third party to not forge messages, but do you also trust them to have adequate storage of the key and adequate protection against application compromise? Or perhaps you trust their key exchange system to be secure against an attacker intercepting or tampering with the exchanged key, but don't trust them not to capture it in a log file somewhere that might later get leaked?

There aren't many situations where you really have to choose between the two constructions. The main one that comes to mind is the JSON Web Token (JWT). My usual advice for JWTs is that if the party verifying the JWT is meaningfully less trusted/trustworthy than the party generating the JWT, use a signature; otherwise use HMAC. However, it really should be decided on a case by case basis.


What issues arise from sharing a SSL certificate's private key?

There are several reasons why wildcard certificates are bad:

The same private key has to go on the systems that have different security levels, so your key is only as good as your least-protected system. Giving it out to third-party vendors is a really bad idea, as then it completely escapes your control.
You have to keep meticulous records that show exactly where your wildcard private key is installed, so that when you have to replace it, you don't have to play "Where is Waldo" across all your sites.
Most importantly, if the private key and wildcard certificate are stolen at any point, the attackers can then impersonate any system in that wildcard space. Common mistake is to say "we'll use wildcard certs on low-security systems, but named certs on all important systems" -- you have to do the exact opposite! If the attackers have *.s.com, they can impersonate any domain in .s.com space, regardless if it's using any other certificates. So if you have "www.s.com" with a wildcard and "login.s.com" with a one-off cert, attackers can impersonate "login.s.com" regardless of what's on "login.s.com".
The easiest way to take advantage of stolen wildcard keys is by DNS poisoning or via rogue wireless APs.

All that being said, you have to evaluate the risks. If your friend S is already giving out this wildcard cert and key to all the vendors, then refusing to accept it doesn't lower his risks in any significant way. You'll just appear obstinate and uncooperative and lose his business. Do your best to educate, but also understand that some people just won't care.

If, however, he's bound to conform to PCI-DSS, then I'm pretty sure he's not compliant, as I think you're supposed to have logs of all access to private encryption keys. I'll let others more familiar with PCI-DSS expand on that.


What prevents the Intel TXT boot loader from being maliciously altered?

Briefly, no.

There's a lot of problem with this diagram so I'll start by trying to clear things up before talking about your question.

SRTM ~ the left part of your diagram

The diagram propose the AC module would measure the processor which isn't right. The BIOS CRTM (Bios Boot Block) is executed by the CPU and used to measure the BIOS firmware. Then, it will return the result of the measurement (SHA1 hash) back to the TPM, not to the BIOS. Afterward, execution is passed to the BIOS firmware.  The same is done for the next element in the boot process. See this for more info.

DRTM ~ the right part of your diagram

Again, the same comments applies. The SINIT AC Module does not measure the processor. Once a secure CPU contained environment is created, the module signature is validated and its identity is sent to the TPM (PCR 17), then it measure the Measured Launch Environment (MLE) and send the result to the TPM (PCR 18).

Both are providing the same thing: a means by which we can measures the running environment (i.e. Root of Trust for Measurements). Technically speaking this means sending measurements in the TPM's Platform Configuration Registers (PCRs) - mainly PCR0 for SRTM and PCR17 for DRTM. Still, we haven't done anything with those measurements.

Ok, now the question.

Briefly, a malicious user can always choose not to trigger a Late Launch/DRTM (TXT's senter operation) but the whole point is that the TPM's PCRs won't have the proper values hence some elements (e.g. keys) won't be accessible. Let me explain:

In the case of tboot boot loader, the Launch Control Policy (stored within the TPM NVRAM) defines which MLE and SINIT module can be loaded (and optionally BIOS, i.e. PCONF). A TXT Reset is triggered whenever the policy is not satisfied. The result of this reset is being unable to perform a Late Launch until the system is restarted. Not being able to perform a Late Launch doesn't prevent someone from using the system - it doesn't stop the boot process or the system by itself. However, it does prevent someone from accessing Locality 2 of the TPM. Locality 2 is necessary to extend PCR 19-22 (and any keys, TPM NVRAM and other resources tied to Locality 2).

What's important to understand here is that Late Launch is not enforcing anything, it's simply providing a means by which measurements are taken and stored in the TPM. Then and only then can we enforce different actions. E.g. if the goal is to build disk encryption, the Operating System could be encrypted with a key SEALed to specific PCRs (17-22) which match the desired/trusted operating system. Now here's the important part: if the proper environment has not been loaded (e.g. a malicious user changed the boot loader, did not triggered a Late Launch) the PCRs values won't match hence the key to decrypt the Operating System will be inaccessible (UNSEAL won't work).

In other words, PCRs values reflects the running environment. The SEAL operation uses those values as keys to encrypt data. If the proper environment is not loaded (PCRs are different) the TPM can't decrypt the data (UNSEAL).

You might want to look at ITL's Anti-Evil-Mail.

Hope this is clearer.


Open source web application penetration testing community

There is already a standard method of reporting vulnerabilities to vendors. CERT is great about contacting vendors and mitigating the issue.

I think that your ideas can be helpful and there is a lot of overlap with your ideas and OWASP.   You should look for a local OWASP chapter in your area.  If one doesn't exist,  MAKE ONE!,  and use it as a platform for your workshop.  OWASP will help get the word out,  and attract more attention to your cause.


Are there specific reasons or benefits to using a tiered information security policy architecture?

The basic idea is that Policies are separated from Procedures because Policies are going to rarely change. They are a high-level view of the intent of the company. Procedures are how that intent is carried out. Those implementational details can vary from department to department and modify over time.

Imagine that the users can have one kind of password complexity requirement, but admins need another. With one Policy and two Procedures (user & admin), you can easily create such a scenario, track and enforce it more easily, and maintain it over time.

By splitting those 2 concepts, you can meet the needs of the company and meet the needs of implementation at the same time.

EDIT

After your clarification, I can say that it's a maintainability issue. An omnibus Policy would need to be reviewed and signed off by each stakeholder all at once, and any change would need to go through the same process. By splitting it up, you can make necessary changes, even small ones, without the need to get the entire company involved.


Can you restrict the services a certificate can access on the client side?

You are mixing the concepts of authentication and authorization. The first is to know who the client is and the second to decide what this client can do. A client certificate in TLS is just used for authentication, i.e. like username + password but only better. If the service you want to access will accept this certificate as authorized  is fully up to this service.

  Is there someway I can sign a new certificate which can only authenticate to one specific web service.

First, you cannot usually create a new client certificate by using an existing client certificate. Also, given that you are not able to modify the service you have no way of specifying which authenticated clients are authorized for a specific service.


Good Practices to secure a Gaming Web Server, Memcached Server & MySQL Server

I would make sure you have these things:

Firewall
Host Based Intrusion Detection system on all your machines (OSSEC is a free one, but you have to tweak the rules a little)
Web Application Firewall

These solutions will significantly reduce the chance of a succesful attack by scanners etc. To have reasonable assurance you should also invest in a pentest.

Now since you have different servers, you should have frontend and backend servers. The backend can contain your MySQL servers since no users should have direct access to them.


Encrypting sensitive data in software and storing/decrypting it on a server

Rolling out your own protocol is hard. You will easily have something which more or less runs, but getting something which is also secure will require a lot of work and a significant amount of luck as well.

From your requirements, you would like a protocol which looks like this:

Each user has an asymmetric key pair, suitable for encryption (say, RSA or ElGamal).
The private key Kpriv is encrypted with a symmetric key K derived from the user password, and then stored on the server.
The public key Kpub is stored on the server with no encryption (it is public).
Data elements are encrypted with Kpub. Anybody can encrypt anything with a public key (that's the point of the public key being public).
To decrypt the data, the user types his password, which is used to recompute K, then decrypt the blob which contains Kpriv. With that asymmetric private key, the user can decrypt all the data files which have been encrypted with the corresponding public key.

The OpenPGP format contains all the needed primitives for that. BouncyCastle is an opensource library which can use that format, and it as a C#/.NET version.


How to remote monitor a computer network traffic?

I'm assuming that what you're doing is related to ethical pen. testing. If you have no legitimate control over your target, you have 3 options

Haxoring your target: Attempt to gain access to the target machine by exploiting some vulnerabilities in the machine itself, or the operator of the machine.
Big Man in the Middle (Between your target and the servers to which he's connecting): Attempt to gain access to the network device used by your target. For example, find some vulnerabilities or default passwords in the routers or gateways your target uses.
Man in the Middle (Between your target and his local network gateway): Attempt to trick your target into sending his traffic through you. By far, the easiest way to achieve this is through ARP Spoofing. An easy-to-use tool is Cain and Abel.

(Cain and Abel)


Do bad passwords produce bad salted hashes?

Salted hashes are designed to protect against attackers being able to attack multiple hashes simultaneously or build rainbow tables of pre-calculated hash values.  That is all.  They do nothing to improve the underlying strength of the password itself, weak or strong.

This also means that they're not designed to defend against online attacks, so they have no impact on an attackers ability to manipulate your login form, where the salt is irrelevant, because an attacker isn't computing hashes directly, but entering candidate passwords into a form that may be (as you said) rate limited or protected by a captcha.

Weak passwords are weak.  Strong passwords are strong.  Salts don't affect this equation in any way.


Do you mean 6 rounds, or cost 6?
Because cost 6 is 2^6 = 64 rounds.

Nowadays cost 10-12 is considered the minimum.
However you need to look the maximum your hardware can handle.

The process of hashing should take approximetaly one second.


OpenSSL fails NIST AES-128-ECB test vectors?

The ecb_e_m.txt file is for "Monte Carlo Tests". These are described in the accompanying katmct.pdf file, section 4:

  Each Monte Carlo Test consists of four million cycles through the candidate algorithm implementation. These cycles are divided into four hundred groups of 10,000 iterations each. Each iteration consists of processing an input block through the candidate algorithm, resulting in an output block. At the 10,000th cycle in an iteration, new values are assigned to the variables needed for the next iteration. The results of each 10,000th encryption or decryption cycle are recorded and included by the submitter in the appropriate file.

So if you use key K = 00...00 and begin with text T = 00...00, then encrypt T, then encrypt again the encryption result, then encrypt again, and so on, until 10000 successive encryptions have been done, then you obtain the value in the NIST test vector (C3 4C 05...). (I confirm this value with my own code.)

The command line you give, with OpenSSL, performs only one encryption, and yields a distinct result, the one you obtain (and which I can confirm, too, with my own code).


A developer crash log may contain personal information (e.g. names of open files or things like that). This depends on the application and on the care the developer put in the process. Generally speaking, if the application contains any personal information at all, then it is hard to guarantee that the information will not make it to a crash log, since crash logs, by definition, occur unexpectedly (if a crash is expected, it is a feature, not a bug).

You can try to reproduce the crash with the same application from a dummy account which, by definition, contains nothing about you. This guarantees a "clean crash log".


How do I tell my wifi device to stick to a channel

I have fixed the problem by purchasing a USB wireless adapter and working in a VM guest kali environment with that adapter. There I do a

airmon-ng check kill
airmon-ng start wlan0

and this preserves the session for the entire monitoring session. I presume in Ubuntu killing all the annoying processes doesn't have exactly the same effect as in kali.


You can use the personality(2) syscall to set the ADDR_NO_RANDOMIZE flag for a process. That process, and any of its children, will not be using ASLR. Do this in whatever process starts Docker.

ADDR_NO_RANDOMIZE (since Linux 2.6.12)
       With this flag set, disable address-space-layout
       randomization.


"Steal" in the scope of what was allowed when you installed it? yes, this is due to Chrome's extensions auto-update feature and there are documented cases of this happening. You can however disable the automatic updater as described in this Stackoverflow answer, the main point is that the code from the extensions isn't compiled and you can edit it rather easily:

Step 1: Find the extension id

You can get this from the web store url, for example: https://chrome.google.com/webstore/detail/cfhdojbkjhnklbpkdaibdccddilifddb tells the id is cfhdojbkjhnklbpkdaibdccddilifddb

Step 2: Find the manifest file

On Windows: C:\Users\<User_Name>\AppData\Local\Google\Chrome\User Data\Default\Extensions

On Linux: ~/.config/google-chrome/Default/Extensions/

Step 3: Edit the manifest file

Browse to the folder where your extensions are, find the folder named according to the id from step 1, browse to the folder for the latest version (usually only one is there) and open the file manifest.json, edit the line for update_url so it looks like this:

"update_url": "https://localhost",

and it should lock that extension to that specific version you are running


How should I store and maintain secure configuration documents?

As some people have recommended, use a configuration management tool like Puppet (recommended), Chef, etc. Use VCS like Git to store revisions of Puppet manifests. Using Puppet, you can define your secure baseline and simply apply it to any number of machines that you want. Add some comments to the Puppet code (Ops code) and you have your "configuration document".


Is SFTP vulnerable to brute force, bounce, spoof, sniffing and port stealing?

Most services are available to brute forcing, and most have mechanisms to defend against it. You can likely use SSHGuard to prevent brute forcing as it written to detect multiple failed anomalous logins, and blocks (via IPTables) the connection. Or you could write your own script with checks and balances:

pseudocode

if
tail -n 1000 /var/log/messages | grep fail && grep sftp
then
cut field of IP and create iptable rule && run rule
fi

The better (optimal) option would be creating a rule to allow instances you trust, and blocking all others.


Risks of sharing information just "protected" by a unguessable url

An "unguessable" link is exactly analogous to a username/password protected link - as you surmise, users could just as easily share the username/password for a guessable link as they could an "unguessable" link.  In fact, because unguessable links can have far more entropy and because they aren't susceptible to bad password practices, it can end up being even more secure.

As far as brute forcing, there are 62^32 possible links in the scheme they appear to be using (upper and lower case letters + numbers, 32 characters long).  That means that even if they could try hundreds of thousands of links a second, it would still take many, many more times than the lifetime of the universe to exhaust the search space.  Even if there are hundreds of millions of links, they could probably try until the sun goes dark without finding one.

62^32 is an enormous number.

(This assumes that the urls are generated randomly, using good sources of randomness and are not predictable.  If they are predictable (hashed from the time + account or something), all bets are off.)


Is sending passwords through cellphone text messages secure?

It is absolutely not secure. Text messages function essentially the same way email does: your client (phone) forwards it to a server, which then looks up a destination which may be on another network (carrier) and then sends it over where it is held in a mailbox until a phone gets it.

Anywhere along the way it can be copied, retained longer than expected, etc. Lawful interception, unlawful interception, cloned phones, Google+ accounts, etc are all ways a message can end up somewhere unexpected and all that assumes you trust the phone and software on it.

Clear text is compromised text. Always.


Do you give local administrator account password to notebook users?

The answer is: It depends.

It depends upon your relationship with your users, and how much they can be trusted to not create problems, and the extent to which you want to support laptops where the user has administrator-level access, and the necessity of administrator-level access from a mission/business perspective.

It's just a question with a bunch of tradeoffs, and you'll have to decide from the perspective of your own organization what makes best sense for you.  The benefit of giving your users admin-level access is, as you identified, it may allow them to solve problems themselves, e.g., while on the road or while your support help desk is not open, or without contacting your support help desk.  The disadvantage is that it users now have the power to shoot themselves in the foot.  They can make changes to settings that render their system unreliable or unusable; they can install software that is malicious, bad, or just contrary to your organization's policy.  You may see those users later at your help desk asking you for help getting their laptop working, because they screwed it up (they may not even realize it is their own darn fault).  On the gripping hand, if you lock down users' laptops too tightly, and you have power users, they may come to resent the IT department for controlling things with such a tight fist, which is not good for your organization.

I would ask yourself what kind of relationship you want to have with your users, what level of support you want to provide, and what risks you want to accept or not accept.

For the most part, this has only a modest connection to security.  There are some increased security risks from giving users admin-level access on their own machines.  However, from a security perspective, even if users don't have admin-level access, they can still get infected by software that steals all their files, so it's not like withholding the administrator password somehow automatically eliminates all security risks.


Can we hide a constant hashed key used for AES encryption of a password?

No. If you embed something in source code, it is available to anyone with the source code.

Under most circumstances, you want each system to have its own keys, so that two users of your software cannot attack each other. In a hosted environment, you want separation of duties between dev an operations - dev should not have the keys that operations uses to protect data, since dev's job description is to write the code not be custodians for the data.

Rarely, you will want to embed your public key to ensure that your software can communicate with your server. This is a little more flexible without hard coding it, and easier to change if not hard coded.

All that said, if you want ask a different question that talks about the problem you are trying to solve instead of just how you are trying to solve it, we can probably give you some better advice.

Since you have changed your question and have added that you are trying to send a password to a web service, I have the following advice: don't do it that way. You are inventing your own crypto protocol to authenticate, and you are planning to only protect the password. If you can use TLS, use that. If you are using SOAP, you can use WS-Security. Your custom protocol doesn't protect against password replay (I don't need the cleartext password, just the encrypted password that someone else sent), doesn't protect other messages sent to the server, and is decryptable by anyone with a copy o f your client software. And don't try to fix your protocol - there are gads of books written about how subtle flaws can destroy the security of a network protocol, and if you try to fix yours, you'll only wind up reinventing TLS (if you're lucky)


Difference between alfa card and my laptop network card?

Every card uses a chipset from different manufacturers. The Alfa card gets recommended all the time as it uses a chipset (Ralink RT3572 on the V2) compatible with the tools you will be using (aircrack etc).

It also has good throughput and if you want to do more than just monitor, e.g Evil Twin etc you will need two NICs anyway, so always good to have a selection.

Your built in NIC may very well have the right chipset and be compatible with the tools. Most cards can go into monitor mode it is only when you start doing more complex work that you may or may not notice issues with your internal NIC.

Another advantage of an external card is the ability to add a better arial. The Alfa comes with a 7dBi antenna as standard, good for picking up a broad range of networks close by. If you need longer, narrower range and have a direct line of sight to your target a 25dBi Yagi antenna gets good results.