why a client authentication is not commonly performed in the TLS protocol?

What is authentication ? That's making sure that whoever is at the other end of the tunnel is who you believe. It really depends on the kind of identity that you want to use.

For most Web sites, the interesting notion is continuity. They do not really care who is connected; indeed, the point of a Web site is to be readable by everybody. The kind of authenticity that a Web site wishes to achieve is to make sure that two successive requests are really from the same client (whoever that client may be). This is because the Web site experience is that of a logical succession of pages, driven by the user's actions (the links on which he clicks), and meddling with that movie-like framework is what the attacker is after. The user and the Web site designers think in terms of sessions and the attacker wants to hijack the session.

This authenticity is achieved by several mechanisms:

Successive HTTP requests from the same client go through the same connection (with the "keep-alive" feature).
SSL offers a session resumption mechanism, which reuses the negotiated shared key (that's the "abbreviated handshake" described in section 7.3 of the SSL/TLS standard).
The HTTP request can include a cookie which the server chooses; typically, a random, user-specific value is sent as a cookie to the user, and, upon seeing it coming back in subsequent requests, the server is convinced that the requests come from the same user.

The cookie is sufficient to ensure continuity.

What extra value would client certificates add ? Well, not much. Certificates are a way to distribute key/name bindings. There are mostly three scenarios where client certificates (in a Web context) are relevant:

The Web server needs an extended notion of user identity, which is defined by someone else. For instance, imagine a governmental service that can be accessed by citizens, but only after proper authentication, e.g. an online election system. What makes the citizen, with his definite name and birth date, is managed by the State at large, but not the same part of it than the one running the service. Client certificates are then a way to transport the authentication from the PKI which issued the certificate to the citizen, to the online election system which is not at all entitled to say who is named what, but must nonetheless keep clear records of who connects.
The system designer has little trust in the robustness of existing Web browsers. If a user's browser is hijacked, then the secret cookie can be stolen and the user has basically lost, forever. On the other hand, if the user has a smart card, and that smart card stores a private key (which is used in combination with a client certificate), then a complete browser hijacking is still a big issue, but it is more contained: since the smart card will commit honourable seppuku instead of letting the precious private key be revealed, the situation can be recovered from. Once the mandatory format-and-reinstall has been performed, things are secure once again.
The Web site does not only want authenticity, it also wishes to get non-repudiation. Non-repudiation is a legal concept which needs some support from the technical parts of the system, and that support is digital signatures. We are outside of what SSL/TLS provides, here. In no way can a SSL/TLS client authentication be a proof which could be used to resolve some legal conflict between the user and the server itself (a bank server cannot show the transcript of the connection and say "see, that user really asked me to buy these actions at that price", because the bank could easily have fabricated the whole transcript). For such things, one needs client certificates and some client-side code which uses the certificate to sign the actual data. However, once the hard work of issuing certificates to clients has been performed, it makes sense to just use them for HTTPS.

In the common case of a Web server, none of these scenarios apply. So client certificates are not used, because they would raise practical issues while not adding any extra value. That would be a solution in search of a problem.


Can my school monitor what I do on my personal device?

The rule is that the admins of a machine can do pretty much anything they want on that machine.
So it is perfectly possible to install loggers that track any site accessed from that machine, and it is easy to do that. It could even be possible to log the full activity (including actions on locally installed programs), but this is only used for very sensitive laptops to make sure that an attacker has not accessed them.
Anyway this will learn you one of the basic security rules: if someone else has control over your device, it is not your device. So you should not use it for something that they forbid.


Bluetooth low energy encryption using chacha20-poly1305

TLS 1.3 has not removed AES-CCM, and it is not insecure. The issue with CCM modes is simply that they are very inefficient, requiring two invocations of the block cipher for every encryption of a single block. The only reason anyone would want to use CCM is if the device in question supports hardware-accelerated AES encryption and does not support hardware acceleration for components of GCM, or because of extreme space constraints that make re-using AES code better than implementing GCM.

The reason Bluetooth is using AES is because it was very important for this version to be fully FIPS-compliant. FIPS is a US government standard that specifies, among other things, the ciphers and modes of operation that are approved for government use. AES and CCM are part of FIPS, but ChaCha20 and Poly1305 are not. Remember that the previous versions of Bluetooth did not even use AES. Instead, they used their own homebrew stream cipher called E0, which turned out not to be particularly secure. It is vulnerable to a variety of attacks, in particular known-plaintext attacks.

An answer on our sister site explains this with more authority:

  I know from being in a meeting that FIPS-140 validation for Bluetooth was an important conversation with the Bluetooth LE spec, which is why AES was added. I can only assume that AES was not used in the original ICs due to cost on the hardware side. Looking at 130nm dies (so, back in the day), AES would cost me about 0.03 USD in area. Just by guessing the area of E0, I would say it's 0.01 USD, so it must have mostly been an economic consideration during the time of early adoption.


On a Linux server, is it safe to store a script containing DBI credentials in the cgi-bin of the DocumentRoot?

Those credentials have to be placed somewhere.  If you decide to place them at a place like /usr/lib/cgi-bin, you'd have to grant your web user access to that directory structure which would in turn make your system more vulnerable.

It is more common to place them one level above the web root as a compromise between the two.  This way you don't open much of your machine to a potential intruder while making it less apparent.  Do note that less apparent is relative to the intruder as many would figure it's part of an include right away.


What risks are associated with public libraries lending mifi devices to patrons?

Those devices are small computers running some flavor of Linux, and just like any consumer-grade router their firmware is horrendous and outdated, so malware on it is definitely possible and likely.

However the malware, if any, would most likely be a generic DoS or spam bot designed to attack the open internet rather than attacking the devices behind it. Most traffic nowadays is protected by HTTPS and client devices are relatively up to date, which means an attacker using router malware to compromise client devices would get a very low return on investment compared to other methods (drive-by downloads, maladvertising, Flash exploits, etc).

So while I wouldn't use one myself, the risk for your client computer seems pretty low even if you do.


Why do some email software products block SSL certificates attached to a message?

Are you perhaps referring to Outlook that is blocking .cer, .crt and .der without giving a specific reason per filetype? More file types were blocked on March 6th 2020, but The Exchange Team doesn't give any more detailed reasoning than this (and many are wondering the same in the comment section):

  Why are we making this change?

  We’re always evaluating ways to improve security for our customers,
  and so we took the time to audit the existing blocked file list and
  update it to better reflect the file types we see as risks today.

Certificate attachments aren't blocked e.g. by Gmail, so it's not a universal practice.

The rationale might be to prevent scams asking to install malicious root certificates, although they have been quite rare on email attachments and mostly seen on web pages. The consequences would be bad, as it would allow intercepting TLS, appearing as someone else etc.

However, I'm not sure whether this really is any good practice, as

it requires more work when you actually need to send a certificate in an email.
it is equally easy to circumvent for malicious purposes.
all Microsoft Office documents are still allowed, having all kind of nasty macros.


What is the difference of the word "Open" in OpenID vs. OpenID Connect

THere is no difference in the word "Open" per se.

OpenID and OpenID Connect are both authentication protocols standardized and overseen by the OpenID Foundation, thus the similarity in name.

The differences:

OpenID is an authentication protocol designed for federating identity from the ground-up, and for nothing else.

OpenID Connect is a standardized authentication layer on top of OAuth 2.0, which is an authorization protocol standardized separately.  OpenID Connect was a response to the fact that many people were using OAuth for authentication, and the use case needed to be properly codifed and supported.


This sounds like a bad case of Security Theater

  Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it.

I say this because in all reality...

  Given enough time, effort, and computing power security is nothing more than a delay.

Of course it gets worse than that. Javascript is an computer based language, which means it must be run by a machine. That machine can be told to ignore your Javascript.

What this really means though is that you're asking the wrong question. What you're really asking:

  How do you keep your forms safe from someone using saved passwords to fill out the form, and then changing the type of the form to read it?

And to this answer it's pretty simple:
Keep your terminal safe and secure. The only way to prevent this kind of attack is to not let an attacker on a system with a saved password in the first place.

Why? Because you have a "spectrum". Let's call it the security spectrum in this simplified example:
At the basis of simple security you have the following:

Security >----------------------------------------------< Ease of Use

In most cases this is what happens:
The more Security you have, the less Ease of Use you have.
The more Ease of Use you have, the less Security you have.

By using a form that has a password in it and leaving it there, you are increasing your Ease of Use and decreasing your Security


Check root certificates and certificate authorities on new PC

Edit 2015-11-25

"PowerShell-PKI" project looks promising

Bryan Lockwood has put a a nice project on GitHub:

https://github.com/bklockwood/Powershell-PKI

And here's his blog post that introduced it

Bryan Lockwood, 2015-02-24, Auditing Your Root Certificates (Archived here.)

You can run the script like so:

Copy Nov2015-WindowsRootCAList.txt to Nov2015-WindowsRootCAList.NOSPACES.txt
Work around a bug: Manually remove the trailing space characters in Nov2015-WindowsRootCAList.NOSPACES.txt.
(Otherwise the script will report EVERYTHING as untrusted.)
(I suggest you use your favorite text editor's search-and-replace-feature and just nuke all spaces.)
Dot-source the script:
PS C:\Powershell-PKI-master> . .\Audit-TrustedRootCA.ps1 3>&1 | out-null
Run the function:
PS C:\Powershell-PKI-master> Audit-Roots -FilePath .\Nov2015-WindowsRootCAList.NOSPACES.txt -OutputPath .\

The script the Windows trust store (stores?) against a list of known-good hashes.

Hashes-list is same as from certutil.

The origin of this hash-list is not entirely clear to me.

So I decided to generate the hashes myself with a bit of Cygwin-Bash-Scripting:

$ certutil.exe -generateSSTFromWU wuroots.sst
$ certutil.exe -dumpPFX wuroots.sst  | grep 'Hash' | tr -d ' ' | tr 'a-z' 'A-Z' | cut -d ':' -f2 | sed 's/$/ /' | sort > wuroots-hashes-pspkiformat.txt

And it turns out: the hashes from certutil and hashes from GitHub are in fact identical:

$ diff --report-identical-files -- wuroots-hashes-pspkiformat.txt Nov2015-WindowsRootCAList.txt
Files wuroots-hashes-pspkiformat.txt and Nov2015-WindowsRootCAList.txt are identical

Related Twitter Thread

This Twitter thread started by German security researcher Hanno Böck led me to the PowerShell project.

Maybe CertUtil and MMC to reset?

There was a great blog article last month:

Mike MacCana, CertSimple CA, 2015-10-12, Yes, you can control the SSL CAs your browser trusts (Archived here.)

Mike outlines a procedure to generate an .sst certificate container with just the default certificates retrieved from Windows Update and then uses MMC to pick and choose from them.

certutil -generateSSTFromWU rootcas.sst
invoke-item rootcas.sst

I haven't tried this, but I'm guessing that throwing out every CA and then simple importing all the default CAs from the SST file should do part of the trick.

Note: I don't know how Windows handles self-signed-CAs in the "Intermediate" store or elsewhere. I think that store is a cache anyway and can be nuked because it will be automatically rebuilt anyway -- but I'm not certain.

Prior art

EDIT. I just noticed that Tom Leek gave essentially the same answer to a similar question last year:

2014-10-22: Reset Windows trusted certificates store to its default


DoS attacks do what you said: they prevent users from accessing the service. DoS by itself does not mean that theft is possible, although sometimes DoS attacks happen in order to distract those running the service from noticing another type of attack or to trigger known remediation processes that the attackers can exploit in order to perform a different attack.

In the case where theft is not the end goal, why DoS? Why do some people pull the wings off flies? Some people just like to watch the world burn.


Data sniffing on a WEP 128-bit encryption

From what I can see, your setup is something like this:

NodeMCU Microcontroller <----> Phone
                          ^
                          |
                          |
              Sniff packets with Kali

Although you have tried sniffing with promiscuous mode, using promiscuous mode to capture wireless traffic might not work:

  Promiscuous mode is, in theory, possible on many 802.11 adapters, but
  often does not work in practice; if you specify promiscuous mode, the
  attempt to enable promiscuous mode may fail, the adapter might only
  capture traffic to and from your machine, or the adapter might not
  capture any packets.

A workaround to this problem is to use monitor mode. Monitor mode is different from promiscuous mode in that monitor mode captures packets without associating with an access point, and promiscuous mode allows you to view all packets on the network you are associated with, even if the packets aren't addressed to you.

You could use monitor mode by passively sniffing packets from networks around you while not connected to an access point.

If the network you are sniffing uses encryption, provided you know the WiFi key, Wireshark can decrypt the packets for you.

TL; DR: Use monitor mode.


As @schroeder said, someone (probably the same ones that control the 208.91.197.39 IP) hijacked the DNS of your registrar.  This means that they changed the DNS records so that the domain (what you incorrectly call "URL") name your customer bought now points to the IP 208.91.197.39 instead to the legitimate IP or domain assigned to your customer.

The reason why they do that are many: for instance to generate traffic for a web site hosting ads/scams/malware, or to impersonate another domain to do frauds.


The script will always have that line as the default is 40 pages. See the manual page you linked. Specifically:

  The script, by default, spiders and searches within forty pages. For large web applications make sure to increase httpspider's maxpagecount value. Please, note that the script will become more intrusive though.


What to do if caught in a physical pentest?

Always have your slip with you!
This is the golden rule of Red Teaming! If you don't have your Permission to Attack with you, it's like driving without a driver's license. That said, if you are caught during an engagement, I recommend the following:

Present a forged Permission to Attack. This way, you can see if criminals could possibly trick a security guard to letting them do their thing with a fake Permission to Attack.

Present the real Permission to Attack. If a guard has not bought your fake slip, then it's time to hand in the real slip. If the guard believes you, it's time to pick up and leave the perimeter. A real attacker would have been stopped at this point. If the guard did not believe you, ask them kindly to talk to their supervisor. If they insist on not believing you and calling the police, so be it. You're not a criminal, so don't worry about it.

Follow the police's orders. They'll take you with them to the station, where you can explain to the police that you are part of a Red Team Engagement, and that you have a permission to break into the company. They will double-check that, calling whoever is listed as the person who signed your Permission to Attack. In the happy case, they'll pick up the phone, explain that you are really hired to do that, and you'll be free to go.
In the not-so-happy case, they won't pick up because it's 4 in the morning and their phone has no battery. Should this happen, you will probably spend the night in the police station. Worse things have happened. Call your employer in the morning, and they will reach the contact at the customer's company for you.

What about the other options?

Saying "I'm a security researcher. You've caught me so I'll just leave"

will not be very helpful. In the eyes of a security guard, you're a criminal, caught in the middle of a crime. You will not have the choice of "just leaving".

Run away like a criminal.

A very bad idea. Probably the worst you could do. If the guard calls the police (they likely will), the costs could rise quite a lot and it would not make the customer happy to know they now have to pay the police for an unnecessary manhunt as well. However, you should absolutely include in your report if getting away from the perimeter after getting caught would have been a trivial effort or not.

Contact the employer to get a "Just continue pass".

That would miss the point of a Red Team Engagement. Once you have a "Just continue"-pass, you are not simulating how a real attacker would act. You would just go through the stuff of the company with their permission.


Storing database password in plain text?

Yeah definitely never a good idea, in general, to show or store passwords in the open.  That said, there are such things as compensating controls.  I.E. physical securities to safeguard viewing of passwords, encryption channels for transporting passwords, as well as bolstered security around your database.  I don't know if there are any compensating controls for your particular situation because everyone mostly looks at passwords in clear text as a no-no, but you can take a look at the NIST standards.


Is there any security risk with a LUKS-encrypted hard drive being improperly unmounted?

LUKS wont't write any unencrypted data to your encrypted partition. The keys are protected by locking them into RAM so they are not persisted.
I would pay attention to all non-encrypted partitions you have got. Make sure you wipe files instead of deleting them, and also wipe the free space of your unencrypted drives regularly to make sure they don't contain any unwanted leftovers. Also make sure your swap partition is encrypted if you use one. https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption


What specific information is used to verify an SSL certificate?

Subject identification in SSL/TLS server certificate is DNS name(s) usually and/or IP address(es) rarely, which are matched against the requested URL. Neither of these determines location. EV certificates must contain some physical location information verified by the CA, and other certs may, which the browser cannot further check; some browsers display some EV info, which the user could check against his/her knowledge of the organization/person that should be running the website.

The validity period is compared to the current time. If a client device has a wrong clock, or none, it can be tricked by a server using an expired cert for a stolen or broken key.

BasicConstraints, KeyUsage and ExtendedKeyUsage extensions if present (and at least the first two should be) are checked to make sure the cert is suitable for the SSL/TLS protocol in general and for the negotiated key exchange. Policies if present could be checked against configuration (or user entry) what policies are required, acceptable, or prohibited, but I don't think anyone does.

The Issuer name, and AuthorityKeyIdentifier (AKI) extension if present, are used to obtain (select) the parent CA public key used to verify the cert, so if they are wrong, the signature cannot be and is not verified.  This repeats up the chain and validity, BC, KU, EKU are also checked up the chain to make sure each cert is suitable to be an issuer (CA).

All certs (including chain) must also be checked for revocation. This is done using information outside the cert(s), namely a CRL signed by the CA, or an OCSP response signed by the CA or other trusted party. Nowadays OCSP responses are usually included in the SSL/TLS handshake by the server (called stapling); if not the browser can fetch them using the cert(s) CRL Distribution Point and/or Authority Information Access extensions. This can provide an indirect check; if you get valid (signed) data from CRLDP and/or AIA.ocsp it establishes those values are right, but if you have trouble communicating it doesn't necessarily mean they're wrong, and if you don't even try (because of stapling) then obviously you don't know at all.

The Public Key in the cert cannot be directly checked; the main point of PKI is for the relier (browser) to securely obtain the public key which it does not already have. The SSL/TLS handshake does confirm that the server has (and uses) the private key corresponding to the public key in the cert; the cryptographic mechanism for this varies depending on the key exchange negotiated.


Is testing for SQL injection vulnerabilities still relevant in modern web applications?

Actually according to OWASP, SQL Injection is on top of the top 10 Vulnerabilities through Web applications.
https://www.owasp.org/index.php/Top_10_2013-Top_10

and there are many papers, article, news about concerns in this subject and every day there is a news about SQL injection attack against famous web applications such as for example Joomla,Wordpress or websites and so on, so we can not say that " modern application don't show any sign weakness against traditional SQL Injection methods" because every day a new SQL Injection method is introduced.


Is TLS v1 really secure for VOIP and video calling?

Can someone easily decrypt TLS v1 sessions with these tools?

Easily, no. While TLS 1.0 can be downgraded to SSL 3.0, which is vulnerable to the POODLE attack, exploiting this requires a MITM attack, and is not possible just through passive snooping. No non-MITM ways to break TLS 1.0 are known, other than attacking the underlying primitives, which is still more difficult than easily, though breaking RC4, if used, has been characterized as "feasible".

The best thing to do would be upgrade to the latest TLS and configure at least one endpoint to refuse weak primitives and key lengths.


Can a telephone caller be authenticated?

In the plain old telephone system (and also avionic communication systems) authentication is built into the communication.

Key exchange is also done previously by meeting people. (In case of avionics by meeting pilots and the command center operators).

Authentication itself is done by human ear by recognizing the human voice.

(I am pretty serious. You cannot encrypt safety-critical hardware in avionics. A malfunction may happen in the air. The "safest" way is not to encrypt at all.)


How to secure mine as well as other people' passwords on the computer used by my receptionist?

Dedicated users. Remove the passwords that are saved and move to a computer use model that don't involve shared accounts. Don't give your receptionist (or anyone but Sys Admins) privileged access to systems. Ideally get all of your users using password storage such as KeePass, LastPass, etc.


Opening a saved web page: Is referer file:// sent?

Your link says it right on the page (emphasis mine):

  A Referer header is not sent by browsers if:

  the referring resource is a local "file" or "data" URI
  an unsecured
  HTTP request is used and the referring page was received with a secure
  protocol (HTTPS).

However, regarding the second point, the referrer-policy response header could cause it to be sent from HTTPS -> HTTP if set to unsafe-url.


Does your system store, transmit, process card holder data along with PAN number?

If you answer yes to at least one statement then your system is in scope and will need to be PCI compliant.

  It is possible that this account number might be an PAN from a credit
  card

It doesn't seem to be clear to you what this account number is, but if it helps you understand the compliance scope:

if every account number is a full PAN, then the system is in scope.
if 1/100 account number is a full PAN, then the system is in scope.
if 1/1000 account number is a full PAN, then the system is in scope.
if 1/n account number is a full PAN, then your system is in scope.
if no account number is a full PAN, then your system is out of scope
if the PAN contains only a subset of the full card number, such as the last four or the first six and the last four the your system is out of scope.

Please keep in mind the statements above apply to your account numbers (might be a PAN) being stored, transmitted or process by your system.

Even if you do not process or take payment and you do store PAN for any purpose (account number) your system will be in scope.


Why should small and medium-sized businesses care about security?

Every business, no matter what it does or how big it is, runs on information
Information has value to the business, so the business needs to protect the availability and integrity of that information
Information has value to others; your customers, your employees, your business partners, and has value to others who can exploit it for their own gain, so that information needs to be protected so that people cannot use it to cause harm
Every business needs to ensure that information is used in the right ways at the right time so that customers, employees, and partners get the benefit they need

These four points mean that there needs to be processes and training in place to make sure that the maximum benefit is derived from information and the minimum impact is experienced when something goes wrong. We call this "information security". Information security is not about technology and it is not about "hackers". It's about the proper handling of information for the life of the information and the business.

Information security processes are not new. Businesses of every size need to handle all assets in the same way. In fact, you can replace the word "information" with "asset" in the four points above, and businesses will not be surprised. Information is as important as assets to a business because information is the most important asset.


How is it possible to do TLS through proxy without anyone noticing?

Normally, when HTTPS is done through a proxy, this is done with the CONNECT mechanism: the client talks to the proxy and asks it to provide a bidirectional tunnel for bytes with the target system. In that case, the certificate that the client sees is really from the server, not from the proxy. In that situation, the proxy is kept on the outside of the SSL/TLS session -- it can see that some SSL/TLS is taking place, but it has no access to the encryption keys.

Some organizations implement a full Man-in-the-Middle by generating a fake certificate for the target server on the fly. They do so precisely so that the proxy can see the cleartext data and scan it to conformance to the organization policy (e.g. automatic antivirus scanning). This can work only if the client (your browser) accepts the fake certificate as genuine, which in turn requires that a special organization-controlled root CA is pushed on the client machine (and in a Windows / Active Directory world, a GPO can do that).

About all major vendors for firewall/proxy appliances offer that mechanism as an option.

Not all organizations deploy such a MitM system, for several reasons, including:

Automatic MitM can be expensive. The proxy appliance may have to be computationally powerful if there are many users; and the product license can be high.
MitM breaks certificate-based client authentication.
Doing a MitM makes sense only if you actually inspect the data, which again increases the computational costs.
The automatic pushing of a root CA does not work with BYOD.
As a rule, users really dislike such MitM.


The target switches do not have IP addresses and most scanners require IPs as targets.
Can you scan unmanaged switches with vulnerability scanners? What scanners can target layer 2?

It's useful to keep the OSI model in mind.
A unmanaged switch without IP solely operates on layer 2. It doesn't know about the higher layers, nor does it care. It looks up the destination MAC in it's table, and switches the packets accordingly. This is done in silicon.
Vulnerability scanners work on layers 4 and up, depending on what they target. For instance a vulnerability scanner looking for problems in Apache doesn't really care about anything else than the application.
Running such tools against an unmanaged switch is just a waste of time. You won't learn anything. Instead you should look at how the switch behaves if you do attacks targeted against L2 devices. Can you fill up the MAC table? Can you crash the switch by malformed packets? Can you do arp poisoning successfully?
That said: unmanaged switches are simple devices. They commonly do not have a general purpose CPU, and no code are running on such switches.


Why do we use Oauth2 instead of Basic Auth in server to server communication using SSL?

If you use "username + password" for auth, sending the password on each request is a problem because authenticating the password is slow because the password is stored using a secure password storage method that is deliberately slow. So you want to use the password once to get a long computer-generated token and send that in the subsequent requests.

The high-entropy (long, computer generated) token can be stored in RAM only or can be stored hashed-once in a database, so validating it on every request is cheap.

It can also be stateless (e.g. HMAC of user id and timestamp, using a key available only to the server) but then invalidation requires storing a blacklist of invalidated tokens instead of whitelist of valid tokens, though hopefully the blacklist is smaller and if the tokens have reasonable lifetimes the blacklist shrinks as they expire.

If you send human-generated password in every request (naive basic auth) - stop.
If you send long computer generated token in every request - it doesn't really matter how you format it in the HTTP request. A benefit of using the customary Authorization header is that a bunch of existing code already knows to not log it. Whether you format the token as Authorization: bearer <40char> or Authorization: basic base64(user_id:token or just first-half-of-token:second-half-of-token), it doesn't matter.

The full OAuth2 is too much code (that can contain bad security bugs) if you don't need it, so you can use something simpler (the simpler, the better). But you need to consider at least the cost per-request and how invalidation works.


How can a font be used for privilege escalation?

Fonts are hard. It's old code. It runs in kernel mode.

Julia Wolf of FireEye, Inc. did an analysis:

Video here: Julia Wolf, 29C3, 2012-12-29, CVE-2011-3402 Technical Analysis
PDF here: Julia Wolf, CanSecWest, 2013-03-08, Windows Kernel TrueType Font Engine Vulnerability
Video/Slides again here. HackInParis, 2013-06-20, Analysis of a Windows kernel vulnerability: from espionage to criminal use, Slides: 303 page PDF, Video: 1 hour on YouTube

Gist seems to be this:

Slide 32:

Outlines are drawn using a Turing
Complete language to manipulate the
graphics state

(And that language seems to be interpreted in Kernel mode.)

Slide 78:

It was the length of the CVT array, stored within
the True Type VM’s internal global state structure.
As a consequence, the TrueType engine now
believed that it held one hundred and twenty nine
elements, rather than the original length of one.

Update 2016-06: General background at Project Zero

Google Project Zero has put together an in depth background blog post about font vulnerabilities in general:
(The specific CVE-2011-3402 from above is not mentioned, though.)

Google Project Zero Blog, 2015-07-31, Mateusz Jurczyk, One font vulnerability to rule them all #1: Introducing the BLEND vulnerability (Archived here.)
Google Project Zero Blog, 2016-06-27, Mateusz Jurczyk, A year of Windows kernel font fuzzing #1: the results (Archived here.)
Google Project Zero Blog, 2016-07-01, Mateusz Jurczyk, A year of Windows kernel font fuzzing #2: the techniques (Archived here.)
For even more in depth background detail: see the personal blog of Mateusz ‘j00ru’ Jurczyk (Archived here.)

Update 2017-01: Windows 10 Aniversary Update now parses fonts in USER mode

TechNet Blogs: 2017-01-13, Matt Oh and Elia Florio, Windows Defender ATP Research Team, Hardening Windows 10 with zero-day exploit mitigations (Archived here.)

  Font parsing is now done in user mode within an AC ["AppContainer"]

(The image that contains that statement seems to be from slide 34 of this presentation: BlackHat 2016, Windows 10 Mitigation Improvements.)


How are docker containers affected by CVE-2021-3156?

sudo Is not installed by default on many Linux Docker images. If it is, then you need to either log in to the container and update it or pull a more recent version from the web. I don't know what kind of options a remote hacker has, to  get a command line and execute sudo commands in general but if this option generally exists, then Docker containers are likely insecure and have been for a long time. It seems however that corporate (or for example university) networks where users have sudo or non-sudo access rights are primarily affected. So, where users have terminal access.


The router has (at least) two interfaces. Your nmap 192.168.1.1 scans against the internal interface and lists the services the router is providing for your LAN (DNS, web interface for administration etc.). That's a different set of services than the services it's providing for the wild Internet on the WAN interface. Scan from the Internet should only list the services you have planned to expose; possibly none on a home gateway.

You can log into your router (http://192.168.1.1) and browse the web admin interface to disable all the services you don't need. E.g. if you don't use HP JetDirect, it's a good practice to disable it even if there's no current vulnerabilities involved. On the other hand, Universal Plug and Play (UPnP) can be used to open inbound ports, exposing your LAN devices to the Internet, and can be consider as a threat.

Port by port with a little help from NETGEAR R6400v2 User Manual. (Usually I wouldn't dig this deep for a single product I don't own, but the arrogant attitude on the NETGEAR Community made me.)

53/tcp (domain). There's no option to turn DNS service of, and it is required as the DHCP server on the router always introduces itself as the resolver.
80/tcp (http). Used for network administration and can't be closed.

Also used for file sharing from USB drive and enabled by default; I'd recommend disabling it (from ADVANCED > USB Functions > ReadySHARE Storage).

548/tcp (afp). Apple Filing Protocol is related to file sharing; disabling ReadySHARE might affect.
631/tcp (ipp). Mac OS X Printer Sharing. (Same explanation as for 9100-9103/tcp.)
5000/tcp (upnp). Like explained, this should be disabled (ADVANCED > Advanced Setup > UPnP).
8200/tcp (trivnet1). This isn't Trivnet. It's MiniDLNA Media Derver (Chapter 8, p. 94).
9100-9103/tcp (jetdirect). NetGear calls this ReadySHARE Printer Utility (Chapter 9). It's controlled with an external utility. Not sure if could be disabled.


Knowing if a malware infected something else than the hdd or ssd

In theory you computer contains several critical devices with software writeable firmware.
We know that there are a couple of bad guys infecting firmware (https://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/).

Pretty much any device connected to your PCI bus could take over your system for example by reading / writing memory.

In theory your hardware could even have been backdoored at the factory.

But to my knowledge so far we have not seen this stuff in the wild. So if you are not being specifically targeted by nation state actors you are not in danger.

Your Avira AV (one of the better AVs out there) would probably not help you since it doesn´t look at your firmware and I I would guess Avira has close to 0 samples of backdoored firmware so far. But yes, if your firmware later drops cheap malware into userspace the malware could get detected.


What if the voting machine is the adversary (Distributed Knowledge/Trust)

For paper ballots you have the tallier being audited or watched constantly by 3 people from your 1000 voters (scrutineers).

It could be something similar with e-voting, I don't know what exactly would work. Maybe you have one way data entry for the vote to go into secure government buildings, with giant display screens where any voter can see a list of anonymous vote receipts to gain confidence that their vote was counted, and a ceremony for ensuring the counting machines inside are working correctly and isn't tampered with during the vote.


Disabling SSL v2 and weak ciphers on client PC's

You might want to read the three excellent answers to the question How does SSL work, where it's all explained, but in a nutshell, the server will select which ciphersuite (and compression) to use during the SSL/TLS handshake, after it receives supported ciphersuites from the client. Since you removed support of certain weak ciphersuites on your server end, they can't be selected for the SSL/TLS transport encryption, even if they are supported on the client.

Edit to add: As has @DavidHoelzer mentioned in the comment below, not all websites have yet moved to TLS, and you don't want to be punishing your users for that. Even the weaker ciphersuites are better than none at all, if you remove support for them on clients. Your users would most likely still use those websites, even if they couldn't connect to the host using HTTPS, and would end up opting for HTTP, exposing them to many more threats in the process. In short - I wouldn't recommend it.


You may already be safe: if you typed your IP address into the address bar of a computer connected to the router, being able to access the router admin page is normal.  The router knows your computer is on the "inside" part of the network, and should be allowed to control the router.

The only time you have a problem is if you type your IP address into a computer somewhere else on the Internet (such as at your local library) and your router admin page shows up: in that case, you need to disable remote administration through the admin page.


What are some examples of viruses/exploits with benevolent purposes?

I doubt you'll find any virus which is completely benign (even fixing a vulnerability after exploiting it is still malicious behavior, even if it is intended to be beneficial), but there are plenty of examples of exploits which are. The most well-known would have to be jailbreak exploits, where a vulnerability in a proprietary and closed system is attacked intentionally by the owner of the device to "root" it and gain better control.

In the past, people released malware (viruses, worms, etc.) for fun. Some people would be particularly malicious, with their software corrupting files or rendering a system useless, whereas others would be relatively harmless, doing nothing more than spreading (sometimes too fast, which does cause harm). Back in those days, people would also occasionally release viruses which attacked other viruses. In fact, the Creeper virus you mentioned was attacked by another virus called the Reaper, which did nothing but attempt to remove Creeper infections. Of course, it was still a virus, so it can't be called entirely benign.

Another example of a "friendly worm" would be Welchia, which spread automatically through networks, patching the DCOM RPC vulnerability used by the infamous Blaster worm. Nowadays however, most malware is made for profit, and the historical "malicious mischievousness" is far less common. If you ever see a worm or virus which attempts to destroy existing infections today, the purpose is usually to destroy the competition so it can run its own payload. Some malware calls this feature "mini-AV".


Why is the use of TAB (%09) characters in the middle a 'javascript:' URL valid?

When an  element is clicked, the link is followed and its URL is
resolved. This causes the string to be processed by the basic URL
parser.
In your example, the parameter is processed in the path state during
which TAB (U+0009) characters, along with carriage return and line
feed characters, are ignored, and therefore do not form part of the
resolved URL.Why does anchor tag remove tab character in URL specified inside href attribute?

As per the specification of Basic URL Parser, the ASCII tab or newline will be removed from the URL (or just ignored).


Poor man's 2FA. Should I use composite passwords and how much does entropy matter?

What this doesn't protect against

You don't really specify which database may leak. If the database of the web application leaks, or if your complete password leaks - eg via phishing - your scheme will obviously not help against that at all, because it's not real 2FA.

What this does protect against

On the other hand, if your password manager database - and the corresponding password - leaks, this will help in certain situations.

If we assume that an attacker knows that you are using this scheme, you are now essentially using the same password on all websites. Your security now depends on the security of the weakest website you registered, and on the strength of your additional password.

Things to take into account

Your second password should be reasonably strong, otherwise the scheme is useless.

Obviously it should also not be the same password you use for your password manager.

I would also recommend that you append this password after the password stored in your password manager. Some websites may cut off your password after X characters, and if X is small, you may end up with just this extra password, which will make leakage more probable and reduce your overall security. On the other hand, if your additional password is cut off, your back where you started (no additional security, but also no additional weakness).

Conclusion

Your scheme may add a small amount of additional security in case your password manager data leaks, although the added usability disadvantage - having to type the additional password - wouldn't be worth the trouble for me. At the most, I would use the scheme for extremely important accounts.

A more reasonable approach would be to have two different password manager databases: one for the less important passwords which you can also use on systems which may be more likely to be compromised, and one for important passwords, which you will only use on systems you deem to be secure. This should achieve the same goal you want to achieve in a cleaner way.


If I use a VPN, can an enterprise proxy insert itself in the middle?

The answer is simple, although there are some items to clear up:

Yes, a proxy can put itself in the middle, and if you are using a network at a large corporation, it's virtually guaranteed that there are servers (aka proxies) between you and the internet.  There is always someone between you and the internet.
However, that doesn't mean that the proxy can intercept your VPN traffic.  Intercepting your traffic is impossible unless you installed their root certificate on your machine (which you didn't).
However (again), that doesn't mean that there can't be other ways for them to cause trouble for your attempts to browse the web

To jump to the chase, the most relevant question is whether or not your DNS traffic is going through your VPN.  This question is a good starting place for that.  If your DNS requests are going through the VPN then in general you should be able to browse the internet without issue (although note that there are still other ways that a VPN might leak information about your internet traffic).

However, if your DNS requests are not going through the VPN, then it is possible for the network to detect and block your traffic at the DNS level (which is where pretty much all browser requests start).  Most computers are setup so that they automatically get the location of the DNS server from whoever is providing internet access - in this case, the corporation you are visiting.  If you are using the DNS servers of the corporation, then they can absolutely track the domains you visit and block you from viewing anything they consider objectionable.

Unfortunately, it can sometimes be difficult to make sure your DNS requests are going through your VPN.  Most computers, unless otherwise configured, will check with your ISP (in this case, the corporation) for hints on where to go for DNS resolution.  As a result it is very easy for your ISP to retain control over the DNS requests on your computer. Of course a good VPN should attempt to make sure that all DNS traffic goes through the VPN channel as well, but it isn't always that simple.  DNS resolution can be a complicated dance between your computers networking system and your browser, and just because you installed a VPN, there's no guarantee that all DNS traffic is going through it, especially if any network configuration has been changed on either your computer or browser.  See the question linked above for a starting point.

So, if the "ISP" is handling your DNS traffic, then they can track what domains you visit and block your access.  However, they would not be able to view the actual traffic you send to that domain, including the list of URLs you visit.


... or just mark it off as a scam?

I would recommend this option, i.e. simply ignore this mail. There is a lot of Paypal phishing mails out there because Paypal accounts are a lucrative target. But given that you don't have a Paypal account in the first place this mail is obviously a scam.

You still should learn from this mail that such mails can happen with sites and services where you have real accounts too. Similar phishing mails are sent also for example to get access to Apple, Netflix, Amazon and various bank  and mail accounts.


How to monitor HTTPS traffic using wireshark?

Type tcp.port==443 to the search bar to filter the traffic to HTTPS only.


It depends a whole lot on the context, and what you are trying to protect yourself from.

What does this information contain?

The information in msinfo32 is structured as a list of key-value pairs, which are themselves part of a tree.

For example, the leaf "System Summary" contains information like OS Name, System Manufacturer, User Name, Time Zone, Available Memory, etc.

Why would anyone want this information anyways?

There are plenty of legitimate reasons to ask a person to disclose this information. The most obvious would be tech support. A user complains that an application always crashes, and tech support asks them to send them the information from msinfo32.

This might help them find common ground between you and other users, who also experience the same problem. For instance, let's say all the users who reported this problem happen to have the exact same build of Windows 10, on the same CPU.

While it doesn't exactly solve the problem, it allows the developers to more easily reproduce the problem, and thus aid them in solving it.

So can I share this info freely?

This depends. If you own the machine, then you are free to do so. If it's a good idea is another question (see below). If your machine belongs to your employer, then there may be policies in place on the disclosure of internal information.

Please check with your employer if you are allowed to disclose this information, and to whom for what reason.

Why would it not be a good idea to post this information publicly?

While it doesn't directly contain personally identifiable information, it may give someone interested in you some information that you might not want to share.

For example, your username might be based on your real name, or parts thereof. If you post the information under a pseudonym, an attacker who knows you in real life may be able to connect this pseudonym to your real identity. For example, the information indicates you have a laptop by "FooBar", model "X-Ample 9001". If the attacker knows you own the exact same laptop, it may be an indicator.

Is this far-fetched? Yes, absolutely. It's probably not something you should worry about.

Another possible threat could be installed software and versions thereof. If an attacker knows you have some software with a known vulnerability installed, then you immediately become a more interesting target, as an attacker can assume that there is some way they can exploit you.

So, what now? Can I share it or not?

I would say it depends on who you share it with, and why. If some tech support you contacted asks for this information, they probably have a legitimate reason for it and you are free to do so.

If a random person asks you for this info, but can't give you a specific reason why, then it's best not to do so.


Placing a firewall—without creating a new subnetwork

Sounds like you are just looking for a bridging firewall.

http://www.cryptolife.org/index.php/Linux_Bridge_Firewall

Graphic below is from the link above:

http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge

"A bridge is a way to connect two Ethernet segments together in a protocol independent way. Packets are forwarded based on Ethernet address, rather than IP address (like a router). Since forwarding is done at Layer 2, all protocols can go transparently through a bridge."


It's been a while since I researched this topic, however, several algorithms exist. At the time of my research (3 years ago), the A5 algorithm was the most used algorithm in Europe for phone and sms conversations (GPRS used a different algorithm). Several variations exist:

A5/0
A5/1: most widely used (deemed the most secure of the three), but cracked by Karsten Nohl in 2009-2010
A5/2

I am not sure if these algorithms are still in use, but I assume the encryption/authentication is still done in a similar manner. Update: the 3G and 4G are probably a lot safer. However, operators often fallback to 2G for normal calls/SMSes. The A5/3 algorithm (aka KASUMI) is said to be used in 3G communications. KASUMI is much harder to crack, and thus it is more simple for the NSA to go and steal the keys.  Update 2: by operating a jamming device, agencies have reportedly disrupted 3G/4G communications, causing nearby phones to fall back to crackable 2G.

Authentication
To decide whether or not the SIM may access the network, the SIM needs to be authenticated. A random number is generated by the operator, and is sent to the mobile device. Together with the secret key Ki, this random number runs through the A3 algorithm (it is this Ki that recently has been compromised). The output of this calculation is sent back to the operator, where the output is compared with the calculation that the operator has executed himself (the operator possesses the secret keys for all SIM cards the operator has distributed).

Encryption
This part is the part that has been cracked. In short, the operator generates a random number (again), and sends it to the mobile phone. Together with the secret key Ki, this random number runs through the A8 algorithm, and generates a session key KC. This KC is used, in combination with the A5 algorithm to encrypt/decrypt the data.

Note: the figure is from a paper by SANS institute, and the explanation of the A5 algorithm crack is based on the presentation of Karsten Nohl. I cannot seem to find a valid link to both of these papers at the moment.


Best way to push data to a client without being blocked by firewall

Universal considerations

It is common for most firewalls and NAT boxes to allow a server to reply back to the machine that sent a packet from the inside. Anything else is an edge case or insane behavior. Therefore, if a game client can initiate a connection to you, we can assume that you can talk back on that channel. The goal then is to keep the connection alive. With both TCP and UDP, NAT boxes will eventually time-out the application if nothing is ever sent.

UDP

Simple and straight-forward, most NAT routers will allow UDP packets to go back to the host that sent them. In real-time games, this is the normal protocol so that frame re-ordering isn't performed on dropped packets. The game and its server are responsible for synchronizing their states from within the protocol. Expect the connection to be forgotten after a minute of silence. DD-WRT boxes default to 2 minutes.

TCP

The overhead of keeping connections ordered is shifted from the game to the system. Packets arrive to the application in order, though this can create some unwanted delays when packets drop or arrive to the computer out-of-order. At least by RFC, NAT boxes should keep an established TCP connection open for at least two hours before forgetting them. Realistically, count on no more than 5 minutes. DD-WRT routers, for example, forget in 10.


Can someone eavesdrop on my home network?

I assume that the wifi you are connected to is an access point hosted on the second router.

If your second router is running a properly configured firewall, the answer is "no"; an attacker who breaches your ISP-provided first router will not have direct connectivity to your computer.  He would be in a position to eavesdrop on any unencrypted connections going from your computers to the Internet (HTTP is not safe, but HTTPS is.)

As far as your WiFi security goes, be sure you are using WPA2, and don't use a trivially easy-to-guess password (don't use your names, etc.) Instead of a password full of hard to remember symbols, try a silly two or three word combo, like "CloudRapidOlive"


Why do I see Network Traffic without any User Activity?

I'm going to assume you ask why you see traffic on your machine, even though you don't actively do anything. The reasons for that are that your computer is doing a lot in the background, which is not triggered by any user action. Let me give a few examples:

Replies to requests: Your computer receives network requests all the time. A good example for that are ARP requests in your local network. Your computer will receive them, and may respond to them. This is normal behavior and required for your PC to work.
OS and Application Updates: Your OS and your Applications will periodically check to see if updates are available. This is not triggered by any actions of yours, but happens periodically.
Background Connections: Some applications open various connections to external services as soon as you open them. For example, Chrome and Firefox both try to reach a specific site to see if captive portals are being used, if ISPs behave correctly, etc.

Of course, there are many more reasons why your computer may show traffic, even if you're not "doing anything".

  Could these contain private information without my consent?

That depends what you consider private information. For example, Firefox sends requests to fetch http://detectportal.firefox.com/success.txt. An attacker in the same network could listen to this request and detect that you are using Firefox.

As far as your consent goes, it depends on the Terms of Service of each individual application. You would be surprised to what things you consent just by using regular applications.

  Could these replies contain personal documents?

Answering a comment, usually no. Of course, if you use a file-sync service such as Google Drive, Dropbox, etc., it is of course possible that personal files will be included in such traffic, but this is by design.

As for other applications, it would be highly unlikely. For example, if you bought a video game from Steam and it would suddenly send copies of all your files to the publisher, such a case would become popular very quickly and would put the developer into hot water (and likely get their game banned from Steam quickly).


Can AWS KMS be used for both KEK and DEK for PCI DSS?

There's nothing within the PCI DSS which would prevent you from using AWS KMS for both the KEK and the DEK.

You should ensure you're generating strong keys, the KEK is equivalent strength to the DEK (e.g. both AES 256-bit), the DEK is encrypted by the KEK and you have separate key custodians for key components.


Detecting port scanning activity of a mobile app

Wireshark is a great tool to analyze packets within the network.

As suggested, you can install Wireshark on a PC that is connected to the same network the iPhone is and see what packets are being sent to your PC.

Ensure you know the IP of the phone within the network, so you know where the packets are being sent from.

EDIT

@matthew - To make the laptop the access point which the phone is connecting through, it'll see all traffic the phone sends to the local network.


Lower level languages like C and C++ may be referred to as "unsafe" languages because it places a lot of responsibility on the programmer to get things right. For example, when you access and array element arr[i] the C compiler assumes that the programmer knows what he is doing and that i is a valid index for array arr.

Higher level languages such as C# and Java treat the programmer like an idiot and do runtime checks to make sure that arr points to a valid memory location, that i is a valid index for this array, etc. These runtime checks add overhead but in consumer applications where efficiency is not as paramount as keeping development cost low.

If you are interested in security then I would suggest that you study C and C++ since you will come face to face with issues like buffer overflows, heap corruptions, use after frees etc.

Higher level languages like Java are designed for people who don't know or care about security and does all it can to hide these problems from both the user and the programmer, which will not help you learn about these problems, it will just teach you to ignore them.

Many applications are written in high level languages but low level languages will always be relevant because someone needs to build the platforms that run the higher level stuff. Nearly all Java runtime environments are written in C++ and nearly all operating systems are written in C. Scripting languages such as Python Ruby and Perl are written in C. Ruby might be a safe language to program in but there could always be a bug in the underlying virtual machine.


Generally speaking, you are correct. Let's look at some exceptions:

If the malware exploits a vulnerability in your email program.
If the malware exploits a vulnerability in the software used to "unzip" it.
If the malware exploits a vulnerability in the software used to view its contents (ie Windows Explorer).
If the malware exploits a vulnerability in the program used to open an extracted.
If the files are used by other software, for which an exploit exists. I say this because you specified "executed" not "opened".
If the software is inadvertently ran by something else. For example, a DLL could be loaded and ran by some other software.


Prey is free, but for the app to work they have to have access to a lot of your information (TANSTAAFL)

Generally if an app is "free" its like any other "free" product on the internet in that they use your actions and track you to sell data about you. Prey may or may not be doing this but at the very least you should assume they track your actions as much as possible to improve their product (especially the paid version).

Looking at the app permissions page on in the google play listing reveals:

Version 1.1.3 can access:
Identity

find accounts on the device

Contacts/Calendar

read your contacts

Location

approximate location (network-based)
precise location (GPS and network-based)

SMS

receive text messages (SMS)
send SMS messages
read your text messages (SMS or MMS)
edit your text messages (SMS or MMS)
receive text messages (MMS)

Photos/Media/Files

modify or delete the contents of your USB storage
test access to protected storage

Camera/Microphone

take pictures and videos

Wi-Fi connection information

view Wi-Fi connections

Device ID & call information

read phone status and identity

Other

interact with a device admin
receive data from Internet
change your audio settings
full network access
run at startup
view network connections
modify system settings
connect and disconnect from Wi-Fi
change network connectivity
prevent device from sleeping


This is not a hash. You always have a base64 encoded data (the one that ends with '==') and the hex value of the decoded data.

I am not sure what type of data this is, but I am almost sure that it is binary data.

AAAAAATOM2KIII+kbR/Dqw3TLTw4PHsGPZft2c+b93rImFIuAQ==
    0000000004CE336288208FA46D1FC3AB0DD32D3C383C7B063D97EDD9CF9BF77AC898522E01
AAAAAASaQwt3IaNVmGiQJxXHm1ZT888dHmAnmYOksBLkChGUYA==
    00000000049A430B7721A3559868902715C79B5653F3CF1D1E60279983A4B012E40A119460
AAAAAASeclRQJiE6vfoIjp8HxTZRaqMxMGMORZqrdSmOAUuFfA==
    00000000049E72545026213ABDFA088E9F07C536516AA33130630E459AAB75298E014B857C
AAAAAAQh51mzdpW5w+/+yK46nezAbMp5xn3XGMRxNBu7wTSWHQ==
    000000000421E759B37695B9C3EFFEC8AE3A9DECC06CCA79C67DD718C471341BBBC134961D
AAAAAAT8KI/Xub72swAm0CPT/1DoS9jig4IyfK6ZnvU+8VGaXg==
    0000000004FC288FD7B9BEF6B30026D023D3FF50E84BD8E28382327CAE999EF53EF1519A5E
AAAAAATYILi+qpLlRt3UACCDwHM5y3kvZhma+za0VmYDjkyRTQ==
    0000000004D820B8BEAA92E546DDD4002083C07339CB792F66199AFB36B45666038E4C914D
AAAAAAQLXlq1CHz1kLFiJ2LKER3y/D2E6ktH8tUva6XzmLfonQ==
    00000000040B5E5AB5087CF590B1622762CA111DF2FC3D84EA4B47F2D52F6BA5F398B7E89D


You're going to need to go through the authorization grant flow again with the 3rd party resource and identity provider in the same way you did with your initial resource and idp.


There is some Android ransomware that is fairly easy to get rid of using Android Debug Bridge. These are older lock screen trojans. Here's a page that has a good breakdown of the types and how to get rid of them.

Some newer Android ransomware is very effective, but if you get one of these, you really have only 2 options - wipe the device or pay the ransom. If you have your pictures, contacts and other important data saved, then wipe your phone completely and restore to factory defaults, then re-install your apps and data. If not, then pay the ransom and get your device back, then back up your important data in the future. Be sure to wipe your device and restore to factory defaults in any case as the malware, or the application that allowed it to be installed, is is still persistent.


EDIT - This is probably based on DIGEST-MD5 or similar - Wikipedia currently claims it's still secure, but there's a "citation needed" in a crucial place.  Using MD5 is generally a bad idea.

The intention of the hash step is to protect against accidental leaking of the token/password.  By hashing with the time, you're basically deriving a shorter-lived token and sending that instead of the original one, so if the derived token were leaked, the original one would still be safe (assuming the security of MD5, so...).

Over HTTPS, this scheme doesn't really offer much more protection than an OAuth Bearer token.  It isn't any worse than an OAuth Bearer token of equivalent length, but the fact they've used this scheme (as well calling their secret token a "public key") makes it reasonable to assume that they're not that hot on security, and that will probably be reflected elsewhere in their business (e.g. securely storing the data you send them).

If you're sending this over plain HTTP, then it is better than just using the actual token - but you have other problems, because you need HTTPS to prevent MITM (because a bearer token doesn't help).


How is it possible that you can see connected clients of an WiFi without even connected with it?

It's because the MAC addresses are seeable in "clear text", or we should say clear waves.
Else how should the wifi router know the received frame is for him ?
See OSI Model. The encryption is in higher layers.


What are the difference between IPS and WAF in terms of DDoS?

Neither of these technologies can prevent a DDoS attack, what they can do is help to prevent a DDoS attack from taking down services. They have completely different functions so you can't say one is better is better than the other.

An Intrusion Prevention System looks for anomalous traffic on a network and can alert operations staff that a DoS attack is underway, and in some cases it may be able to block some of the traffic. The main benefit here is the alerting capability though, notifying operations people so they can swing into action and keep services up.

A Web Application Firewall will, if configured properly, filter DDoS traffic before it overwhelms the applications behind it.

In reality, unless the DDoS attack is pretty low-level neither is going to be that much help, as a powerful DDoS attack will overwhelm both. The most effective DDoS protection is at the perimeter of your network, using traffic filtering and rate limiting on your border network devices. It also helps to have a plan in place to contact your upstream ISP and ask for their help in filtering the DDoS traffic.


Yes, your first answer is correct -- if done client-side, you've then its essentially the hash of the password is the password.

The usual practice is to do it serverside via HTTPS.  Yes, people on the server side can in principle see your password, but they also have full access to all the data your password can see/change.  This is a very good reason to never re-use passwords at different sites and to use a random passwords for each site kept in an encrypted password manager (like keepass).

Note there is a third option, the Secure Remote Password Protocol which is more complicated, but prevents both of the attacks described above.  It requires both client-side and server-side hashing and uses modular exponentiation (similar to a diffie-hellman key exchange).  Granted, at the moment the SRP is not widely used as it isn't built into webbrowsers yet (and doing it in JS allows a straightforward attack from the server-side by changing the JS to something that sends the password in plaintext from the browser).


Secure boot for devices which don't have hardware security element

Yes you can. You can use eFuse to store public key of the root certificate. This becomes root of trust. eFuses can be written only once and once eFuses are blown by writing bits into the eFuse array, it is not reversible. To prevent physical tampering with first stage bootloader, it must be burned on non-programmable storage which must be physically hard to replace and may damage the PCB if an attacker tries to. You can use CPU die for this. Using the public key, it can validate signature on second stage bootloader by using PKI. Second stage bootloader can be hardcoded with public key that verifies the kernel and kernel verifies system.
To revoke public key of root certificate, you have to provision empty eFuse arrays which can be later blown to write new public key by pushing OTA updates. To revoke public keys of later stages in chain of trust, replace their hardcoded public keys and recertify their signature. For rollback protection, store last known running version of second stage bootloader in eFuse as well which can be validated on each boot. If you run out of eFuse arrays, you can no longer revoke root public key so they should be used when there is absolute necessity.
Qualcomm Snapdragon and Samsung Exynos SoCs are known to use eFuse to kickstart root of trust and to verify warranty status.


Is it ok to use the same password for many services with two-factor authentication?

If that other factor is enough to protect your security for you, then sure.  The point of multiple passwords is that if one is compromised, they aren't all compromised.  If you reuse the password and one account is broken, that factor is broken everywhere it is used.  If you don't mind a one time code being all that stands between an attacker and your Gmail account, then there is no reason not to use the same password.  It is certainly far less secure, but it's also far more usable.  It's a personal choice based on what you think the tradeoff is between security and usability.


Can I used Google Authenticator with Radius and VMwareview

Google Authenticate stems from the OATH (Open Authentication) group, and is based on RFC 4266 and RFC 6238.  You could implement it using Pluggable Authentication Modules on your RADIUS server.

Check out this thread and this.


What are the risks of a rogue Access Point?  What lessons can be learned from the Wifi Pineapple?

First and foremost, the pineapple demonstrates the concept of a rogue AP, as that is essentially what it is.

Every wireless card that has been configured to automatically connect to a previously known network will get connected to the pineapple. This is a hardware implementation of the karma attack.

Once connected, the pineapple becomes a powerful tool for conducting MITM attacks, coming with a good range of tools built in.

The pineapple can also be extended using modules that provide functionality like sslstrip, tcpdump and nmap.

Mitigation techniques that apply to standard MITM attacks also applies to guarding against the pineapple. One very interesting technique that is pineapple specific is to set a network with a name like pineapple as the SSID as the priority trusted network. If your card connects to that network, it means you have fallen prey to the pineapple. I read about it in a blog post about the pineapple, but i can't find it now.


Can malware migrate between OSes on the same machine?

They are not correct. Anything left in memory after the machine reboots, even if not overwritten, won't be active. This is because there is no code in any used operating system which looks in unallocated space in memory and executes anything that looks like code. While it is possible for specially designed malware to be cross-platform and to infect another operating system by virtue of having access to the storage device it resides on, it will not be able to persist an infection by staying in memory after reboot. For a more comprehensive description of the boot process, see System Initialization (x86) - OSDev.

Note that this only applies to system memory. In theory, malware that runs on the GPU may persist across reboot. The reason for this is that a warm reboot just resets the CPU. It does not power cycle peripherals, so a discrete GPU will still be executing code and retaining memory throughout the boot process. Malware that is made to run on the GPU may then use direct memory access to re-insert the malicious code in the main operating system. However, this will be fairly hardware-specific, and will not work if the device is booted up from a cold state (i.e. power is actually cut, including to the GPU).


Does there exist any exploit to read someone's old emails, but not recent emails?

Even though I am not aware of an explicit exploit, I would draw a different conclusion. Anything that is security related should expire, because you can not know what will be possible in the future and because a token is a form of credential.

Here are some more reasons I would take into consideration, other than the (personal) backup.

Most important, reusing an old token would be complete non-detectable for the legitimate user. If the attacker must send a new token, at least the user has a chance to get a new mail notification etc. (I am aware of at least one real incident where a user has informed the IT department because of suspicious notifications on their phone for mails they could not find in the inbox - the attacker delete the mail right after they copied the data needed).
Mail is usually stored and forwarded a lot between servers. Thus besides the personal backup you need to consider that the the mail was at some time stored on any of the involved mail servers, maybe even backuped.
Your mail has passed most likely through several spam filters along the way and this be process by systems you might not be aware of.
Someone might have recorded a LAN/WIFI transmission where your mail was not encrypted (plain SMTP).
Once used, the link can show up in the browser history, even synced to other devices as well.

So while it seems to be hard for an attacker to target a specific user through old emails, there are still several attack vectors for abuse of the token for any user of your system.

In the end, you will have to check it against your threat model.


What is the difference, from a security perspective, between a USB Hard Drive and Flash Drive?

There is no difference

From your computer point of view, both disk are the same kind.

There are some little differences in how information is deleted, but it should not matter regarding prohibition.

A Flash Drive will usually have a smaller capacity, but if they were concerned about leaks, several gigabytes allow for losing a lot of information.

Maybe they just think that since a flash drive is smaller it will be easier to lose it while larger drives won't? That doesn't seem too reasoned.


Make secure connection with help of a server

Congratulations, you have just invented the Virtual Private Network or VPN! They are usually used for all your communications and not just for a specific server. In addition, they also hides your real IP from the servers you connect to.

Do note though, that the connection will still be unencrypted between your VPN exit (the server in the middle) and the server you are connecting to.


Detecting (and locating) rogue PXE server on a local area network

If PXE (TFTP) server information is provided to the clients via DHCP options, then you may need to prevent that someone could set up a rogue DHCP server in the network to provide the clients with the adress of a malicious TFTP server. DHCP snooping may help you: it will allow DHCP reply messages (such as DHCPoffer) only in ports that have been configured as trusted by the network administrator. These trusted ports should be the ports where legitimate DHCP servers are connected to the network o where DHCP replies coming from the legitimate DHCP server are expected.

Besides effectively preventing rogue DHCP servers to work in your network it will also allow you to detect such servers and where they are connected if you monitor the log messages generated when DHCP snooping violations occur


In general and as explained in this ServerFault answer, you need to

add the software vendor's public key to your keychain
get the signature (*.asc)
verify the signature via gpg --verify $THE_SIGNATURE_ASC $THE_FILE

Exact details and commands are in the answer linked above and in the link provided by @Steffen-Ullrich in your exact case.


Hardware devices for protecting against BadUSB?

I hope someone will contradict me with solid arguments, but "The USB hub will not allow firmware write commands to devices connected to it.": this seems to be the wrong assumption which makes all the hardware BadUSB protection system to vanish.

There is indeed a related and very informative post: How to check if my USB stick firmware can be rewritten via the USB port?. One could learn there that there is no generic "write" command: each vendor use their own commands for this purpose. Even worse: with some vendors we should more talk about "tricks" than actual commands, LvB mentions "USB stick's or USB HDD's that when written to an extreme address instead of writing it to disk, write it to the internal memory".

How could such a hardware filter something which cannot be detected and is just part of the normal device communication flow?


Website Implementing https site w/ self signed certs and CA

If this is a publicly accessible website, then use a certificate signed by a recognised CA. Downloading a random certificate distributed from the HTTP or the self signed HTTPS site is highly insecure. You are not only compromising the security of your website but also potentially the security of unsuspecting users who installed your root certificate.

Self-signed certificates are only useful in closed system where you have a secure secondary channel to distribute your certificate, where your users can validate with certainty that the certificate that they are about to install actually being to your site. The root certificate itself is a public key and is not considered a secret for HTTPS security, but if you distribute your root certificate through insecure channel, your users have no way to know for sure that the downloadable certificate in your unencrypted site actually belongs to the same site as the encrypted site or if their or your HTTP/self signed HTTPS connection might have already been MITM-ed, and the attacker has replaced your root certificate with the attacker's own root certificate. If the attacker managed to convince your user to install this spoofed root certificate, thinking it was from you, they can now MITM the HTTPS connection that your user thought is a secure connection to your site, without any browser warnings.

In short, use a recognised CA. Or distribute your certificate in such a way that your users can validate that it really is yours.

If you need HTTPS, there is really no reason not to get a certificate from a recognized CA. Some CAs, e.g. StartSSL, now provides basic validation certificates for free for personal sites (unless you are handling potentially illegal materials, which is another matter altogether).


I don't think you need to be too concerned. There are many legitimate reasons to have the UDP processes you have identified.

As you have noted, lsof can be used to find out which program is associated with the socket. Note that you will need to use sudo to run the command if you want to see information for processes which are not owned by the current user.

The . is the interface and port. If the interface is *, it means that the socket is bound to or can bind to all interfaces i.e. 127.0.0.1/localhost the IP of your ethernet or wireless interface and possibly the 224/multicast interface.

If the port is listed as *, it normally means there is no active connection to the port and there is no defined or well known port used by that service or it is a service that allocates ports dynamically and there is no current connection. When there is a connection, there will also be something listed in the status column, such as LISTEN, ESTABLISHED etc.

UDP ports are broken up into 3 basic groups 0 - 1023 used for common, well known services. Ports 1024 - 49151 for IANA-registered port use and 49152 - 65535 which are available for use by services and can be assigned dynamically as needed (assuming nothing else is using the port of course).

With respect to general security, there are a few basic principals you should follow

Turn on the OSX firewall. This will limit what can connect and to what ports. In general, the standard config allows your services to connect to external addresses but only allows external address to connect to you for either ports you allow or when it is part of some already established session - for example, if you have initiated a service which as part of that service, the remote system needs to communicate back to you on a UDP port.
Disable any services you don't use. For example, if you don't use OSX data sharing services, turn them off. Likewise, if you are connected over a wired connection and don't need wireless, turn it off. If you don't use/need location services, turn them off etc.
Some services can be configured to only listen on specific interfaces or only allow connections from specific hosts. This is more common with TCP, but can be done with some UDP based services. However, you need to be careful as you can break or adversely impact on a service if you restrict it incorrectly.

The key point is that you don't rely just on a single layer of protection. You have multiple layers so that if one layer should fail (due to a bug, misconfiguration, zero-day vulnerability etc) other layers of protection may provide protection. For example, I have a firewall on my OSX system, a firewall on my router and various security settings on my internal networking switch.

One of the benefits of something like OSX over Linux (for example) is that it has pretty reasonable defaults. Provided you follow the advice/best practice recommended by Apple, your in a pretty good position. However, one of the disadvantages of this approach is that it is often much harder to tweak the configuration to meet your specific needs. With a Linux system, you have full control and can tweak it to be as locked down as you like. However, you also have the power to completely screw it up. With OSX, Apple has taken some of that power away or made it very difficult to get to, so you have less chances of screwing it up. However, when Apple screw it up, then everyone is at risk. The other problem is that because it is so standardised,it provides a bigger target. Linux, with less standardisation means that if someone wants to find an exploit, they also have to find a Linux box with just the right mixture of software and configuration in order to have assurance the exploit will work. This is why I use my Linux system for high risk situations/environments and my OSX system for low risk situations. I spend less time tweaking and configuring my OSX system and it is convenient. I spend more time with the Linux system and while it is less convenient, it is more secure.

It should be noted that as UDP is a connectionless protocol which does not have the 3-way handshake of TCP, the security threats are a bit different. UDP is sometimes referred to as an unreliable connection because it does not have all the checks and balances of TCP sockets. It is used where loss of datagrams or datagrams arriving out of sequence is not a problem. It therefore tends to be used when you want to send/receive simple and low importance data. It isn't suitable for bi-directional communication where the order of packets is important and there is likely to be a 'session' involving a bi-directional conversation/communication. This doesn't mean you can't do such things, but that it is typically harder and less reliable than a TCP connection.

One of the most common threats based around UDP is denial of service. Because there is no handshake in the protocol, it is very easy to spoof the originating source IP. Many of the reflection and amplification denial of service attacks use this technique. For example, I could use the NTP protocl config flaw which allow you to query an NTP server over UDP to request a list of all the servers which have used it to synchronise their time, but instead of having my IP address associated with the query, I spoof a victims address. The NTP server receives the request and sends the response back to the spoofed IP I used. This is the reflection part. As the response is much large (more bytes) than the request, the data returned is larger than the data sent - this is the amplification part. If I do this to a large number of NTP servers, suddenly my victim starts receiving all these UDP datagrams it did not request. You can't do this easily with TCP because when I spoof the address, the destination I send the data to immediately tries to do a handshake with the spoofed IP I used. The real host with that IP will receive this handshake attempt and essentially go "eh What?" and the handshake will fail because it did initiate and doesn't know anything about the connection.


I couldn't find information on how to manage key in such a way that
  once the originator-usage period has expired, the database can still
  get decrypted as the recipient-usage period is longer.

Quite simply, when they say "usage period", they mean "period during which you will use the key this way."  They are not suggesting that you alter the key, only the way you use it.

To quote NIST SP 800-57 "Recommendation for Key Management"

  A symmetric key shall not be used to provide protection after the
  end of the originator-usage period

They are not asking you to destroy the key, merely to stop using it to encrypt data at the end of the OUP.  You will also need to stop using the key to decrypt data at the end of the RUP, which implies that by the end of the RUP you have re-encrypted any data with a newer key which you will use instead.


How is the Heartbleed exploit even possible?

@paj28's comment covers the main point. OpenSSL is a shared library, so it executes in the same user-mode address space as the process using it. It can't see other process' memory at all; anything that suggested otherwise was wrong.

However, the memory being used by OpenSSL - the stuff probably near the buffer that Heartbleed over-reads from - is full of sensitive data. Specifically, it's likely to contain both the ciphertext and the plaintext of any recent or forthcoming transmissions. If you attack a server, this means you'll see messages sent to the server by others, and server responses to those messages. That's a good way to steal session tokens and private information, and you'll probably catch somebody's login credentials too. Other data stored by OpenSSL includes symmetric encryption keys (used for bulk data encryption and integrity via TLS) and private keys (used to prove identity of the server). An attacker who steals those can eavesdrop on (and even modify) the compromised TLS communication in realtime, or successfully impersonate the server, respectively (assuming a man-in-the-middle position on the network).

Now, there is one weird thing about Heartbleed that makes it worse than you might expect. Normally, there'd be a pretty good chance that if you try and read 64k of data starting from an arbitrary heap address within a process, you'd run into an unallocated memory address (virtual memory not backed by anything and therefore unusable) pretty quickly. These holes in a process address space are pretty common, because when a process frees memory that it no longer needs, the OS reclaims that memory so other processes can use it. Unless your program is leaking memory like a sieve, there usually isn't that much data in memory other than what is currently being used. Attempting to read unallocated memory (for example, attempting to access memory that has been freed) causes a read access violation (on Windows) / segmentation fault (on *nix), which will make a program crash (and it crashes before it can do anything like send data back). That's still exploitable (as a denial-of-service attack), but it's not nearly as bad as letting the attacker get all that data.

With Heartbleed, the process was almost never crashing. It turns out that OpenSSL, apparently deciding that the platform memory management libraries were too slow (or something; I'm not going to try to justify this decision), pre-allocates a large amount of memory and then uses its own memory management functions within that. This means a few things:

When OpenSSL "frees" memory, it doesn't actually get freed as far as the OS is concerned, so that memory remains usable by the process. OpenSSL's internal memory manager might think the memory is not allocated, but as far as the OS is concerned, the OpenSSL-using process still owns that memory.
When OpenSSL "frees" memory, unless it explicitly wipes the data out before calling its free function, that memory retains whatever values it had before being "freed". This means a lot of data that isn't actually still in use can be read.
The memory heap used by OpenSSL is contiguous; there's no gaps within it as far as the OS is concerned. It's therefore very unlikely that the buffer over-read will run into a non-allocated page, so it's not likely to crash.
OpenSSL's memory use has very high locality - that is, it's concentrated within a relatively small range of addresses (the pre-allocated block) - rather than being spread across the address space at the whim of the OS memory allocator. As such, reading 64KB of memory (which isn't very much, even next to a 32-bit process' typical 2GB range, much less the enormous range of a 64-bit process) is likely to get a lot of data that is currently (or was recently) in use, even though that data resides in the result of a bunch of supposedly-separate allocations.


Application with direct datatabase access: store private key in database

Provided you are properly using a NIST-approved authenticated encryption mode (such as AES-CBC & HMAC-SHA with proper KDFs & IVs, e.t.c.) breaking this should be as difficult as simply breaking an encrypted file. Now, depending on your use case this could/could not be enough. I will take you through a couple of other options I myself can think of, as well as the potential security benefits/drawbacks it may offer.

Option 1: Standard authenticated encryption with encrypted private key stored in DB

This (as mentioned before) will be security-wise just as good as encrypting a file in the same way, and should be as hard to break as the underlying encryption. However, it offers one major drawback: this allows an attacker to destroy/irreversibly modify the private key data, because this simply is not part of the encryption threat model (it only cares that the data is secret and cannot be modified without being detected). This is where I propose solution no.2:

Option 2: DERIVE the private key using the user's password

This option is involves (basically) feeding your derived key into a PRNG and generating the private key every time (whenever you need the private key, you just derive it from the user's password), this has the advantage of

not even being stored in the database,
the private key (obviously) cannot be corrupted now, because it is not stored anywhere.

However, this option may be a little more risky than option 1 because of two reasons:

PRNGs are generally considered inferior in terms of security to block ciphers (such as AES)
Depending on your choice, a brute-force attack on the underlying password MIGHT be faster than trying to break AES
The number of possible private keys is now inevitably much shorter (due to the nature of a psuedorandom number generator).


If I use an AWS machine to connect to "Website ABC" through VPN, will "Website ABC" know I'm connecting from an AWS machine?

For TCP/IP to work (the connection protocol the internet is built on), it MUST known a destination and source.

A VPN (it the consumer sense) alters the routing of information in such a way that there is no direct path to the requesting party (yourself) from a destination (a website).

If you access a website from a AWS machine, the destination party will know your AWS machine's IP address.

If you access a website from a AWS machine, which then tunnels its connections through a VPN, then the destination party will see the VPN's IP address.

Web Links:

What are the advantages of paying for a VPN service as opposed to hosting your own?


Wordpress wp-config file seems hacked and changed to DB_NAME and DB_USER asadmin_drr and DB_HOST as 46.21.253.40

This info needs to be escalated to your hoster and probably some authorities (if you're in the EU and have user data on that instance), because someone set your DB connection to a DSL line terminating in Moscow.


Can I use a text editor to detect keystroke injection?

I suggest you to use a virtual system to make a separate lab to test that drive. After that you can check the system log, and look for modified parameters, as recently executed commands.
Besides, you should see the actual keystroke injections, if there are any.
You also should have access to the drive, am I right?
Try to disassembly, and look for a microSD card. That way - if it is really a bad usb/rubber ducky/malduino - you can read the payload directly from the microSD card.


Block size of CTR, CFB and OFB mode of AES in openssl

Yeah this is explainable by how these modes work.

Note: The input to the mode must be a multiple of the blocksize. (That's why this can be lower than 128-bit for a 128-bit cipher)

Now observe how CBC works: NewBlock(LastCiphertextBlock,PlaintextBlock):=Encrypt(LastCiphertextBlock XOR PlaintextBlock)
As you can see this can only encrypt a multiple of the actual blocksize of the cipher.

Now let's see how OFB works:

NewBlock(State,Plaintext):=State=Encrypt(State);return State XOR Plaintext

So you're basically encrypting some state over and over and use this state as pad to encrypt the plaintext. Thus you're converting your blockcipher into a streamcipher. As the application can now store the state and only generate new states as every old bit has been used, one can encrypt arbitrary data sizes.

Now let's investigate CTR:

NewBlock(Counter,Plaintext):=Counter++;return Encrypt(Counter) XOR Plaintext

As you see this is the exact same logic as with OFB, you generate the pad using some state (the counter). As you can store this pad until the next pad-block is needed you can encrypt data bit-by-bit.

Finally let's dive into (n-bit-)CFB:

NewBlock(LastCipherTextBlock,Plaintext):=Plaintext XOR Encrypt(LastCipherTextBlock)

So again you're converting to a stream cipher, but this time you take the previous ciphertext block (which is known), encrypt it and XOR it against the plaintext. As you can once again store the pad and perform no blocksize operation on the plaintext, you can use arbitrary plaintext sizes.


IMAPS (aka "IMAP within SSL") can be configured with a requirement for a client certificate (that's bi-authenticated SSL). You could setup the IMAPS server that way, and request certificates issued by a custom CA and distributed in smartcards (or smartcard-equivalent USB tokens, which is easier since these do not need specific readers). Finally, the smartcards could require a PIN code, which then counts as 2FA (one factor is possession of the smartcard, second factor is knowledge of the PIN).

Unfortunately, not all IMAPS clients support client certificates (e.g., on an iPhone, it apparently requires jailbreaking and some extra effort)(good luck on plugging a smartcard in an iPhone anyway...). Also, setting up a PKI and enrolling smartcards, that tends to be, let's say, a bit expensive.


Is it safe to sync private keys between iOS devices using iCloud?

I'd scrap the direct syncing option and simply allow the user to export their private key to a location of their choice, e.g. iCloud, DropBox, internal storage, etc., in an encrypted format.

On export I'd do something like this:

Ask the user for a password to use. Don't impose any restrictions on them - it's their job to use a good password!
Use a strong key-derivation algorithm such as PBKDF2 to generate a storage key. Use a decent number of rounds.
Prefix the private key blob in memory with four known bytes (a magic number), e.g. 'NATG', to form your plaintext.
Encrypt the plaintext with AES-128 or a similar block cipher, in CBC mode, using the storage key and a randomly generated IV.
Export the ciphertext and IV into a file.

On import:

Extract the ciphertext and IV from the file.
Ask the user for the password and generate the same key using PBKDF2.
Decrypt the ciphertext using the IV and key.
Check that the first four bytes of plaintext match your known bytes. If not, it's the wrong password. If so, we're in the money!
Remove the first four bytes and you've got the private key!

This allows users to quickly and easily sync private keys via the communications service they want, whether it be iCloud or DropBox or even email, with a reasonable level of security. If their account gets broken into, the attacker still has to crack their password. If they've used a decent one, PBKDF2 should do a decent job of making their cracking attempt infeasible.


Is plugging my computer directly into a college network a security risk?

TL;DR

Get good AV, use a firewall, and be skeptical of things you download and links you click on.

  I'm using Windows 8 with the standard Windows firewall turned on, and
  I've scanned with malwarebytes without finding anything. Am I at risk?

Anytime you connect to a network with other users, there's always a risk. That risk is decreased with the use of firewalls, AV, and a generally skeptical mindset regarding all sites you visit and things you download. To quote the X-Files... Trust No One. Don't click on suspicious links, or download unknown files from the Internet or email. If you do download anything, scan it with a well-known AV. Alternatively, you can upload it to Virus Total to see what other AVs have identified in that file.

  What should I do now? I've been using my bank, Facebook, email etc.

The reality is the Internet can be appear to be slow at times. Think about where you are. At a college when everyone is coming back to school. Bandwidth may experience congestion and appear slow at times -that's probably normal. If you really want to test it, go to a local coffee shop or Internet Cafe when there's low traffic, or test the school network at a time when there should be low usage (i.e., 6am). If your computer functions as expected, chalk the slowness up to congestion.