What kind of data can be monitored/intercepted/altered by the VPN service provider?

You asked a couple questions:

  What kind of data can a VPN server log or monitor?

Date, time, which server you connected to (IP and port), the size of the request, the response size, how many times you connected to it.

  Can the VPN service provider monitor or intercept the full length of the transmitted data, or are they able to do so for some part of it?

It depends. If the connection is encrypted (TLS, SSH, for example), the provider can intercept the message but cannot know its contents, as the encryption is meant to protect exactly against this kind of attack. If the connection is not encripted (FTP, Telnet, HTTP, POP3, and others) they can monitor and intercept everything.

Not only monitor, but copy, alter, and replay any message. Logged into a plain FTP Server? Your credentials can be copied. The files you transmitted can be copied or changed.

  Also, can they alter and re-transmit the data as it passes through the VPN server?

Same as above.

  How do I know that the provider isn't doing such thing?

The Terms and Conditions. Yes, that boring page full of legalese that almost nobody reads. Usually they will tell there (in cryptic language) what they monitor and what they don't.

Will they monitor you? Probably. Like every single Facebook beacon, every Google Analytics script, everything on everywhere you navigate. It's bad? Not worse than everything around you. And that's a legal thing to do (unless they say they will not monitor).

Will they steal your credentials and your data? Unlikely. Besides being illegal on almost every jurisdiction, it would bury their business pretty fast. They have other means to make money, and stealing data from their customers isn't the best one.

How to be sure you are not being monitored instead of protected? Rent your own VPS and install your own VPN. It may seem complicated (and it's not simple), but with the correct tutorial you can have a Linux installed and running wireguard in an afternoon, for less than 5 dollars a month.


What does " oscrashed.xyz " do to a computer?

It appears that this website loads a lot of new pages in the browser, as you can see from the source code:
<script type='text/javascript'> window.location.href = 'chrm'; </script>
A quick look at the source code and a scan by VirusTotal don't show any other malicious activity, so you're probably safe, but you might consider an antivirus scan just for extra safety.
There are other, similar webpages designed to crash Chrome and other browsers, including Safari, as this article states:

The website is http: // crashsafari.com. Please be responsible with this information and do not send it to anyone as a joke.
By its name, it sounds like a way to target Apple's browser only, but Chrome and Firefox are impacted too. On my Ubuntu laptop, running Chrome, the entire browser froze. I had to force close it in order to continue. Some Chrome on Windows users report that only that tab crashes.[...] While it can be argued that this is nothing more than a prank-worthy nuisance, remember -- some people work exclusively in the browser. This could result in important work being lost. Rebooting an iOS device entirely can cause a ton of lost app data.


I'd try to go with established tools first, before writing my own networking interface monitoring code.

Chances are that if you're trying to protect a server, you'll be helpless against a sufficiently large DDoS anyway (someone further up the routing chain will have to take action to null-route attacks), so the main argument in favor of writing your own C code, efficient detection, isn't very strong).

(The above paragraph doesn't apply if you're trying to detect a DDoS flowing through specialized hardware, like large routers - in such a case, you'd be part of the effort to stop a DDoS before it reached it's target, and efficiency would be your prime concern - but I'd be disappointed if  high-capacity routers didn't already have such capabilities built-in)

Besides tcpdump, you could also use netstat (to get a quick idea about the number of connections or connections in a zombie state), iptables (both to log packets and then act on the log, and to drop suspicious packets immediately) and fail2ban (you can configure it to count, say, HTTP GET requests or SSH connection attempts etc, and then automatically ban the IPs in question, and of course also produce log messages that an additional DDoS detection script can the pick up and use to notify you).

One problem with basing detection code for a DDoS on the server that's being DDoSed is that if you're counting on the server to notify you of the attack over the network, you might get disappointed because the server might not have the CPU resources or the bandwith available to send out a notification any more. So you'd need to have a secondary means of communication, say a GSM modem over which to notify you (and that's assuming that the server still has the CPU resources available to run your notification code).

There's another, very easy and much more promising way to create a DDoS monitor: Set up a small script on another server that periodically tries to connect to your server. If it fails to connect, you can assume that either your server is down, the network between your server and your monitor is down, or that there is a DDoS in progress. Going this route, you don't even have to write any software at all; just subscribe to an online service that checks service uptimes. There's a lot of them available, some of them even for free.


It depends upon the ODBC driver. If the driver has internal crypto, you can activate it. However, it also depends upon the backend database. ODBC may be used to connect to databases other than SQL server. For example, a native Oracle ODBC driver written on top of Oracle's DB client can use oracle network security when connecting. Other ODBC drivers may not use or have native security.

EDIT for Clarification

ODBC - Open Database Connectivity - is an API (library) within a program, it is not a network protocol. There's the Driver Manager, which is what is linked into the program and then there are Drivers which connect to various databases that are dynamically loaded (often) or statically linked (infrequently) into the program.

The program can exist on the same machine as the database (and use interprocess communication) or remotely on another machine (and use network communication). As there is no universal network protocol for accessing every type of database, each driver has its own network protocol, if it's network capable.  For example, in the case of ODBC/Oracle, there would be a specific ODBC Oracle Driver that slots under the ODBC call stack and converts ODBC calls into SQL*Net calls. Those calls may be secured (the point of your question) using Oracle's Advanced Security Option (its native network security).

Likely, you're using a different database. In that case, you'll need a different ODBC Driver that, hopefully, has a secure networking layer built into it.

Years ago, I worked for a startup that specialized in building secure ODBC drivers for Oracle, Sybase and Generic ODBC networking. For the generic ODBC driver, we wrote our own client/server network protocol that used Kerberos and DCE RPC for securing network communications and the server side would call into the database via another ODBC Driver Manager.


Is it safe to rely on UUIDs for privacy?

UUIDs generated following RFC 4122 come in several “versions”; in a UUID of the form xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx (in hexadecimal), then:

If 8 ≤ N ≤ b and M=1 or M=2 then the UUID identifies the machine that generated it and the time it was generated.
If 8 ≤ N ≤ b and M=3 or M=5 then the UUID is generated deterministically using a cryptographic hash function.
If 8 ≤ N ≤ b and M=4 then the UUID is random (with 6 fixed bits and 122 random bits).

If the UUID doesn't meet any of these constraints, it wasn't generated according to RFC 4122. But even if the constraints are met, this doesn't guarantee than the RFC was followed, or that the random generator was a good one.

I don't know what S3 does for UUIDs.

Even if the UUIDs are properly random, which would make the URL unguessable, protecting access to a resource with only a URL is a bad idea. URLs tend to leak in many ways: shared in emails or chat, lying around in browser histories and bookmark lists, accidentally copied around, or worse, left as a link in a page that the author meant to keep private but that had no authentication and got indexed by Google.

If you want to protect access to a resource on the web, do not rely on the URL being kept secret. Add an authentication mechanism. Even plain old password authentication is a huge improvement on an unguessable URL — browsers and even people know that they shouldn't be sharing passwords around, whereas URLs are normally public knowledge.


Is a reversible microphone kill switch in hardware plausible?

Well, yes, it's called a switch.

Microphones from a hardware perspective are (in the case of electrets, at least) a capacitive component which produces a small current when the membrane moves due to sound. By amplifying this signal you can capture a sound signal.

By simply disconnecting the audio line from the mic itself, or just turning off the amplifier circuitry, you cut the input and no longer provide any audio to the hardware. It's as simple as unplugging a 3.5mm jack from your phone, except with a switch.


In a TLS handshake, the "Finished" messages contain a value which is a hash of all the handshake messages exchanged so far (for this handshake). If the attacker alters the ClientHello then the hash will not match: when the second handshake completes (the first and only handshake in the view of the client, the second handshake from the point of view of the server), the client sends a 'Finished' message that the attacker cannot modify (it is encrypted & MACed with the newly negotiated key), and that message contains a hash computer over, among other things, the ClientHello that the client sent. If the server saw a distinct ClientHello (one without the renegotiation extension), then he will compute a distinct hash, the "Finished" contents will not match, and the connection will be aborted.


tracing an email address with out receiving an email from the subject

You can send them an email and embed an IP tracking "image" into the email.

There's a lot of websites providing this service.

This will of course work only if they open the email.


Do we have any Events code for Unix as we have in Windows.

nope. what you have is a bunch of software that writes logfiles, but these logfiles do not follow any standard.

  If Not, On what basis can we write alerts for unix flavours or machines . for Auditing,application or network based alerts.

network-based attacks are usually detected by a NIDS like snort, suricata, bro (open source) or whatever commercial IDS you use. any decent SIEM should have connectors for these kind of alert-systems.

the same applies for hostbased-intrusion with tools like OSSEC or other opens-source stuff that works on logfile-analaysis. for any serious NIDS/HIDS and SIEM you'll find connectors and ways to inject events from that system into the SIEM


If I am not logged into my company's WIFI, can they view my information? Or am I transmitting?

If you are connected to a mobile network instead of your companies wifi they shouldn't be able to view traffic coming from your phone. However, if the phone is a work phone (provided by them) then the statement above may not apply; they could have installed applications designed to monitor employees.


Is there a security risk in using pointers instead of struct instances?

I don't know the specifics of the routine you were asked to amend, but I can tell you the following.

When you allocate memory on the heap, even if you correctly de-allocate it, there is no guarantee that the contents of that memory is erased after you're done with it.

On the stack it's the same deal - however because of the way the stack works - that memory is more likely to be overwritten in short-order (heck, the next function might overwrite it).  With memory allocated on the heap, the time for it to be over-written is indeterminable from your perspective as a programmer.

So to answer your question - an attacker might be able to read the memory in both instances - but during the course of running your program, the stack is potentially going to be overwritten immediately, whereas the data in your heap allocation would be much easier to find long after your program deallocated it.


Is my company VPN the same as third-party VPN providers?

It depends on how the VPN is set up. One of the possible setups is the following:

VPN connection to allow remote access to internal network servers of the company, but all other traffic is direct from you to the internet (so not routed through the VPN).
All traffic is routed through the VPN making all traffic between you and the company secure. All other traffic is secure from you until the first hop of your company's VPN server but from there on it's plain internet.

Without more information / testing it's impossible to tell how your setup is or if your company uses 1 of these schemes or a different one (there are a few  more that are basically somewhere in between these 2).


How secure is TeamViewer for simple remote support?

There's a couple of differences between using a 3rd party supplier (such as teamviewer) and a direct remote control solution (eg, VNC)

Team Viewer has advantages in that it doesn't require ports to be opened on the firewall for inbound connections, which removes a potential point of attack.  For example if you have something like VNC listening (and it isn't possible to restrict source IP addresses for connections) then if there is a security vulnerability in VNC, or a weak password is used, then there is a risk that an attacker could use this mechanism to attack your customer.

However there is a trade-off for this, which is that you're providing a level of trust to the people who create and run the service (in this case teamviewer).  If their product or servers are compromised, then it's possible that an attacker would be able to use that to attack anyone using the service. One thing to consider is that if you're a paying customer of the service, you may have some contractual come-back if they're hacked (although that's very likely to depend on the service in question and a whole load of other factors)

Like everything in security it's a trade-off.  If you have a decently secure remote control product and manage and control it well then I'd be inclined to say that that's likely to be a more secure option than relying on a 3rd party of any kind.

That said if the claims on TeamViewers website are accurate it seems likely that they're paying a fair degree of attention to security, and also you could consider that if someone hacks TeamViewer (who have a pretty large number of customers) what's the chance that they'll attack you :)


Question about email app in Python and security

I ran into the same issue when using a Ruby gmail gem.

According to this post, "less secure apps" directly handle your credentials, rather than using something like OAuth that verifies your identity without exposing your credentials to the app. Given that your app is running locally on your machine (and you hopefully trust it!) this shouldn't be a problem.


Take a look at this fantastic blog post that was recently published by security researcher Robin (@digininja) about this exact topic:

Direct view with content-disposition: attachment - not vulnerable - Headers are sent to force the file to be downloaded.

Direct view with CSP - not vulnerable - The Content Security Policy is set to disallow inline JavaScript.

Image Tags - not vulnerable - The SVG is referenced through image tags which prevent scripts.

Tags With CSP - not vulnerable - Image tags and the same CSP as above for double protection.


Keyed-hashing a password with a hash of the password + salt as the key, is it safe?

This hashing method is a handmade construction, which, like almost all handmade constructions, is weak.

In this case, it commits the two cardinal sins of password hashing:

The hashing function allows for parallel attacks.
The hashing function is way too fast.

Here, if two users have the same password, then they end with the same hash. This means that if the attacker has a thousand password hashes to work with (e.g. he dumped the corresponding database table through some SQL injection), then he can hash a potential password and look up the hash value in the table: the attacker attacks 1000 passwords simultaneously, for roughly the same cost of attacking one. This is very bad. Salts are meant to avoid that, but this works only if each salt is used for one hashed password, not for all the hashed passwords on a given server.

As for speed: a basic PC will go through several millions of SHA-512 instances per second. Not many user-chosen passwords resist for a long time when the attacker can try millions per second...

@paj28's suggestion is somewhat better, however not as optimal as could be wished for. Using a hash of the username concatenated with a server-global value (but distinct from server to server) ensures some sort of worldwide uniqueness; however, if a user changes his password, then he will use the same "salt" (since this is on the same server, and the user did not switch names, just passwords). The attacker who could get the hashes of the old and the new password will still be able to attack both in parallel. This is better than the previous method, but still not perfect.

Also, the speed issue remains, and it is serious enough to warrant anathema on this proposal.

Read this answer to learn how password should be hashed, and what theoretical concepts are at work here. The short answer is: use bcrypt.


Is this algorithm for a random string cryptographically secure?

In your code, you have to fill $legal_characters with the list of characters that you accept as part of a password. E.g.:

$legal_characters = "abcdefghijklmnopqrstuvwxyz";

if you want passwords consisting of lowercase letters (all lowercase latin letters, but no other characters and no accents).

This code is a bit weird; it uses mt_rand() (an internal PRNG) seeded with the current time and the process ID to get the length of the password, between 15 and 60 characters. Then it uses /dev/urandom for the password itself, which is smart since mt_rand() is not cryptographically secure (especially since the process ID is not something which is very secret, and neither is the current time).

The actual password generation work thus: it produces 500 random bytes (from /dev/urandom), then removes all those which are not in the set of accepted characters (that's the "tr"), and finally truncates again the remaining sequence of characters to the desired length. This process generates uniformly random sequences, so that's good, and /dev/urandom is the appropriate PRNG for that. Note, though, a few caveats:

If the set of "legal characters" is small, you could end with a shorter password. E.g. if you want passwords with only digits from 1 to 6, there will be, on average, only 12 or so matching bytes in the 500 random bytes. The code has no failsafe for "too short". If you set $legal_characters to all 26 lowercase letters, then about 1 byte in 10 will be legal (byte values range from 0 to 255, and 26/256 is close to 1/10) and, on average, the "tr" part will yield about 50 characters, and it is extremely improbable that it will yield less than 20. Still, this is worth noting and there should be a failsafe.
It makes little sense to have a variable length for the password. If a password of minimal length is acceptable security-wise, then all passwords could have that length. And if it is not acceptable, then why do you use that minimal length ? You'd better use a single, fixed length, rather than a range. This would allow you to remove seed_random() and mt_rand_custom(), substantially simplifying the code.
A "password" is something that a human being will be able to type an memorize -- hence "word". Will he memorize a 60-character sequence ? I am sure there is a medical name for such a condition.
You should set the length of the passwords to an "appropriate" value such that the entropy will be high enough. If there are x legal characters and the password length is n, then the entropy will be xn. What entropy is needed depends on the intended usage. For authenticating users on a Web site, through an appropriate SSL tunnel, 240 ("40 bits" of entropy) is more than enough, which translates to 9 lowercase letters (269 is greater than 240).
The code uses unixisms (/dev/urandom, head, tr...) and will have a hard time running on, say, a Windows server (and PHP runs on Windows, too).

Summary: the passwords will be strong, but the code is weird. You should drop the variable length, and if your users can swallow 60-character passwords, then please congratulate them for me. Or sell them to a zoo. Here is a simplified code which should be OK (warning: I do not use PHP so I am improvising here):

function generate_password() {
    return shell_exec('head -c 500 /dev/urandom | tr -dc abcdefghijklmnopqrstuvwxyz | head -c 9; echo');
}


Vulnerabilities for multiple kernel versions that are installed on a given server

Do I really need then to be concerned about vulnerabilities discovered
for older installed kernels (which are in fact not used to boot the
system)?

A non-running kernel with vulnerabilities does not pose a threat to your system; the kernel must be booted for those vulnerabilities to become an issue.  So if you truly never boot the older kernels, you are not exposed to the vulnerabilities.  That being said, ...

Is there any risk involved?

From Qualys' point of view, they cannot know if the machine is rebooted into a vulnerable kernel at times, they simply know that it is possible.  And so they assume the worst and include those vulnerabilities.
The most secure option would be to remove the old, vulnerable kernels.


Where can I get information on unfixed security holes in an OS

The National Institute of Standards and Technology (NIST) provides a very well maintained database of vulnerabilities.

You can find it here: https://nvd.nist.gov/vuln/search

Also in the recent past a lot of national Computer Emergency Response Teams (CERT) have been established, that provide these kind of information to interested people that are maybe not as - how shall I put this - "experienced" as others. Just google for "< your country here > + CERT". The german CERT for instance, has a great service called "Bürger CERT" that provides information about IT-security to the main street.

BUT - and this is very important - if you don't have any IT background at all, your machines run OS this old, I can tell you right now, that the likelihood of a risk occuring is preeeeetty high. If these are key machines, hire someone to do this and upgrade them ASAP.


Where can I find a mentor/teacher in computer security?

There is a global Infosec Mentors project.

From the website:

  Whether you are a seasoned veteran researching your millionth exploit, a network guru
  gone freelance consultant, or a CS grad looking for your big break, there's something for
  everyone in the mentorship program. As a mentor, we are looking for participants in
  the Information Security community with skills ranging from the highly technical to the
  richly experienced. For mentees, bring your passion and energy.


PCI DSS 3.0 and card swipe terminals for our merchants

All those merchants will ultimately be responsible for their own compliance and this should be enforced and monitored by their acquirer. They will generally have to complete a Self Assessment Questionnaire, my guess being SAQ B-IP which includes a PED with IP connectivity. That SAQ also includes the PCI DSS requirements 9.9 to which you are referring. If you don't own those devices and you're not responsible for their management, then is the responsibility of the merchants themselves to adhere to those requirements.

Given that you provide the devices to the merchants, you could provide guidance on how they should manage those devices securely, maintain an inventory, identify whether or not they've been tampered with etc but you don't have to do this.


From the source code of the meterpreter persistence script, the delay parameter is passed to the VBS executable that is created.

When you check the VBS creation code, you can see that it runs WScript.Sleep

When you say that persistence does not run sleep(), I assume you mean that it isn't running that function in in the shell, and it isn't. But it is running the similar function in the VBS executable.

Remember to always check the source code. The answers are always there.


You have contradictory information: nmap says the port is filtered but nessus says that the vulnerability is present on the system. They cannot both be true, one of these must be wrong. Given that metasploit is unable to connect it is likely that nessus is reporting incorrectly, or is basing the vulnerability report on information gleaned from other open ports. If you look at tenable's page on that advisory you will see that nessus can test for it using port 139 or port 445, so 139 is probably open, and may be exploitable.


This likely will become a problem, if you simply try to use tresor-xts-plain or tresor-xts-plain64. While I haven't tested it extensively, even when I tried TRESOR even with cbc-essiv, it resulted in a non-working system. Only cbc-plain worked, which does use a single key. The way I personally use TRESOR is with tresor-cbc-plain chained with serpent-xts-plain64. I assume that if someone performs a cold boot attack against me and manages to obtain the serpent key will not be able to perform malleability attacks against the cbc-plain, because cold boot attacks are not particularly stealthy. While there are some other weaknesses with cbc, confidentiality is typically still maintained.

However, there may be workarounds. There is a patch to hypervisor BitVisor, called TreVisor which can use TRESOR with XTS keys. I haven't read through the patch extensively. Perhaps looking at the tresor_xts_crypt() function could provide some insight. Its main page is here, in the middle.

There is also RamCrypt, which uses TRESOR to encrypts memory pages of individual processes. It uses the XEX mode of operation, which is similar to XTS (it also uses tweak keys, but the tweak key is the same as the data key). The ramcrypt_page_crypt() function may be a good starting point. Its main page is here.

TreVisor, at least, has a clever workaround for this problem. As XTS mode requires an extra key, the tweak key, TreVisor simply uses a key of half the size (128 bits rather than 256) for encryption, and uses the free 128 bits to store the tweak key. I believe RamCrypt does something similar. See the read_key_0 and read_key_1 macros, and the up argument for the encrypt_block and decrypt_block macros in the TreVisor patch.


Is using Google Voice number for two-factor authentication a big mistake?

The main problem with this would be when someone has malware on your computer (such as a keylogger) they would be able to get your Google Voice password as well as your normal account password.  They could then get past the two factor authentication.  If you always access Google Voice from a separate system you'd still technically be two factor though.


malware that is able to "read" someone's screen or take screenshots of it, making even the usage of multifactor authentication vulnerable.

There is a wide variety of legal and illegal remote access software which enable the attacker to fully control the system, see the remote desktop etc. Some banking trojans integrate this facility to work around onscreen-keyboards the user might use. There are also mobile applications which capture the SMS used sometimes in 2FA or online banking.

  If there is a malware that is capable of something like that how can someone protect from it?

There is no special way just for this kind of malware. This means the same protections are used as against other kind of malware. And same as with other malware you have to be aware that no antivirus or whatever security product will catch every malware.  Thus for best security use dedicates machines which are only used for this specific task (like online banking) and where you don't do normal surfing, mail reading, ..., i.e. all the ways how malware usually spreads.

There are also hardware products which can be used together with 2FA and which are not affected by malware because they just have this single purpose minimal system which cannot be simply updated to integrate malicious functionality. Using these for 2FA is more expensive but also more secure.


I don't like answering these questions because as Poly said they're almost impossible to answer, but this is too long to fit in a comment.

This IS common for a non-specialist IT-Security-related job (as you said, it's graduate-level). You're not a specialist with 10 years of experience.

Don't worry about this, at this stage of your career you'll do almost everything. I'm almost sure that 9 out of 10 IT guys will tell you that in the beginning they worked in many different areas until their career settled and took a clear path.

My advice to you is this: You're a graduate, don't over obsess about final career at this point. Keep it your mind, think of it as a goal, but don't become obsessed. Focus on getting into the working life, gain as much experience as you can, and later you'll have the chance to be picky.

Best of luck.


Has Microsoft released a patch for MS17-010?

Yes, it was patched. This page lists all the patches for MS17-010 across the different Windows operating systems and versions.

You can also disable SMBv1 for improved security, by following the steps listed in this knowledgebase article:

  For desktop operating systems:

  Open Control Panel, click Programs, and then click Turn Windows features on or off.
  In the Windows Features window, clear the SMB1.0/CIFS File Sharing Support checkbox, and then click OK to close the window.
  Restart the system.

  For server operating systems:

  Open Server Manager and then click the Manage menu and select Remove Roles and Features.
  In the Features window, clear the SMB1.0/CIFS File Sharing Support check box, and then click OK to close the window.
  Restart the system.


If you want to ensure that only people that have your software are able to decrypt it and if only the people with the finished program need to be able to decrypt it then you should be ok since only people with those particular versions of the programs have the key.

It can not be emphasized enough, however, that anyone who possesses an installation of the software also possesses a copy of the key.  If the software can decrypt it, so can the person who runs the hardware the software is running on.  To try to make it so the user can not access it goes in to the realm of DRM and is really a hopeless cause unless you control the hardware.

Note, for efficiency gains, you could accomplish the same thing by encrypting with a unique key every time and then only encrypting the key twice.  This would greatly enhance the speed of encryption and decryption as a much smaller amount of data (the key) has to be encrypted/decrypted twice.  It also simplified changing one of the keys if a key becomes compromised since only the file keys need to be re-encrypted.


Is it possible to modify the last time a user logged into Windows?

It is possible when Windows logs the login event in the event viewer, it takes the login time from the system clock set.

So a user could adjust the time and date then log back into the system which would log the event using the changed time/date, then then clock could be adjusted back to the correct time/date. this would show the last login as anything the user wanted.


There’s a bunch of discussion embedded in your question.

Personally I would never trust Geek Squad, but most people don’t have a viable option.

First of all, make sure you understand that you are handing over everything currently on your machine, most things recently deleted from your drive, and many back versions of things on your drive. Do you trust this information with whomever?

Ideally you have backups, but most people don’t and that’s why they are trying to get their machine fixed in the first place. If you can backup or “image” the drive first, great, but most people can’t do that. Even if you did, who’s to say it’s a real copy of what was provided?

The most practical thing you can do is record exactly when you hand over the machine for repair by obtaining a time stamped receipt. This is the most likely basis for any future legal challenge.

While it’s technically possible to plant evidence with consistent time stamps, realistically it’s more difficult to get it right than one might think.

Legal “Chain of evidence” becomes a very powerful argument for a good attorney, and a chain that runs through “Geek Squad” is less than ideal from a prosecution point of view. That said, the detailed forensic analysis of the "Time Line” is still a potentially powerful factor for both prosecution and defense.

The unfortunate reality when it comes to criminal system forensics is that the prosecution is well funded, but the defense is mostly on their own and public defenders are not funded to hire forensic resources.


How can we safely allow a client to perform penetration testing?

Non-Disclosure Agreements
A NDA is a fairly standard thing in most penetration tests. No serious penetration tester will protest against an NDA.
The company conducting the penetration test may later approach you and ask you for your permissions to anonymously talk about the findings at your company for educational purposes, which you can always deny if you feel it would harm your business.
This could look like "In a penetration test for ACME Corp., we were tasked with testing a SaaS solution. During the test, we found that ..."
Details on who is performing the test
It makes sense to know who the actual testers are, just in case you need to contact them directly for one reason or another.  However, you should keep in mind that not all penetration testers have certifications yet, especially those who just started out. So it could very well be that a company may decide to also assign a newly hired penetration tester to the project so they get more experience, in addition to an already experienced team.
Restricted Scope
This is also very usual to see in penetration test projects. It's up to you to define the scope of the assessment, and as such also what kinds of tests a penetration tester is allowed to perform.
Testing Environment
Again, the scope is up to you. If you say you would rather offer a staging server than production, that is very reasonable. In fact, I always prefer testing on staging than on production environments, because I don't want to be the reason thousands of customers suddenly can't access their software anymore, simply because some exploit code I ran crashed a machine by accident.
A copy of the report
That's another reasonable request to make. In fact, you're getting a penetration test done on your software and you don't even have to pay for it. That's a win for you!


What is the significance of Spectre and Meltdown?

There are a few things that make Spectre and Meltdown different from historical cache attacks. Some are specific to the attacks, and some are simply a consequence of the changing computing environment.

Stuff that's different about the attacks:

They're really hard to fix. These are hardware problems, and in the case of Spectre are hardware design problems rather than implementation bugs. Fixing hardware is slow, expensive, and hard to verify. You can't just fix the problem with software updates, the way you can with most security bugs. The "patch" for Meltdown is more accurately described as a work-around than a fix (rather than fixing the underlying problems of userspace programs being able to read arbitrary kernel memory, you just un-map the kernel from userspace programs so there's nothing to read, and eat the performance cost of a context switch on every system call). Spectre doesn't even have that; the closest we've got is things like degrading the precision of JS timers (which may negatively impact some legitimate code) to make it harder (but not impossible) to detect the timing differences.
They're fast, reliable, and easy to carry out. Any language that supports high-precision timers and contiguous-memory arrays with arbitrary indexing (i.e. approximately all of them) can be used, in a very short block of code that is easy to port from one language to another, for successful exploitation. They can be used to extract quite a lot of should-be-hidden data (easily KBs, often MBs or even 100s of MBs) every second. That's a big difference from older attacks that often could only maybe get anything useful, if they had a good long while to work on it.
They allow targeting arbitrary memory addresses, and don't rely on waiting until the processor is doing the thing you want to inspect. Previous cache attacks were mostly focused on seeing what was in other programs' cache lines, which means the attacker couldn't pick and choose what they got. If you know the other program is doing crypto, you might be able to extract the key, but if you mess up your timing (see the point above) or can't force the data you want to access to be accessed (and thus in cache) when your attack is running, too bad. However, Spectre and Meltdown allow reading arbitrary memory addresses of your choosing, which means you can do things like walk data structures to find exactly the information you are looking for.

Stuff that's different about the computing environment:

Cloud computing is common. It is far more typical now, than at any time in the recent past, for two unrelated and mutually-untrusted entities to be running arbitrary code on the same physical machine. Just as processes divide JS sandboxes from the rest of their address space and OSes divide process address spaces from each other, hypervisors divide VM physical address spaces from each other. The very premise of safely in the cloud ("running code on other people's computers") is built on these divisions, and Spectre/Meltdown breaks them.
JavaScript is ubiquitous and useful. What was once a toy language with no use for high-precision timers or typed and bounded arrays has become a very powerful language with most of the features found in other application programming languages. Browsers cheerfully execute code from arbitrary and often untrusted sources (web servers), relying on the JS sandbox to prevent (most) malicious uses of this power. For attacks like Spectre and Meltdown, which bypass the sandbox's protection and can be written in JS, it is an ideal attack vector usable against nearly all end-user machines.


Due to sourceforges step-by-step guide you can set an alias for the canonical host name in the Subject tab during the creation of a CA-signed host certificate. The guide says:

  [...] For host certificates, the common name must be the FQDN to which
  you wish users to connect. This need not be the canonical name of the
  host, but can also be an alias. For example, if pluto.example.com is
  your web server and it has a DNS CNAME entry of www.example.com, then
  you probably want the Common Name value in the certificate to be
  www.example.com. [...]

I this what you intend to do? If not, provide more information (if possible).


Interpolique: transparently preventing SQL Injection and XSS with base64 encoding, what happened?

Summary. I'd speculate that Interpolique was not successful for several reasons.  One important reason is that Interpolique was, perhaps, not solving exactly the right problem, and there are a number of other similar approaches in the space with similar or better properties.  Another possible reason is that it may not have been marketed in the optimal way.  Also, I'd speculate that market demand and difficulties of monetization may have played a significant role.

Background.  Interpolique is a generic idea for defending against injection attacks.  Injection attacks are a broad class of vulnerabilities; the most familiar examples are SQL injection and XSS.

Kaminsky's slides do spend most of their time talking about SQL injection, but I think it would be a mistake to assume that Interpolique is solely or primarily about SQL injection.  Kaminsky does start out by explaining Interpolique in the context of SQL injection defense.  However, after introducing the basic idea (in the context of SQL injection), he then explains how it applies to XSS and other injection attacks.  I'd speculate that perhaps he framed the discussion in this way as a pedagogical device: because it is easier to explain the ideas in a simple setting, such as SQL injection, before discussing how they generalize.

It is also useful to know that Interpolique is one step in a line of work on defending against injection attacks.  It is preceded by BEEP (which was badly broken) and then Blueprint (which shares many similarities to Interpolique, and has many similar strengths and weaknesses).

Not solving exactly the right problem. At the most general level, Interpolique is trying to solve the secure string interpolation problem.  This is the right problem to solve.  Security issues with string interpolation are responsible for a broad variety of injection vulnerabilities.  However, Interpolique's novelty is in the part that is, arguably, not the most critical part.

To address the secure string interpolation problem, there are a bunch of issues that need to be addressed.  How do we escape or encode the untrusted data, so it cannot break out of the context it is supposed to be confined to?  How do we tell what context the untrusted data is being inserted into?  How do we know what is the right escaping/encoding function to use, for that context?  How do we integrate the solution into web application frameworks?  How do we educate developers about how to use it?

Interpolique's most novel aspect is the method it uses to encode untrusted data so it cannot break out of its context.  Interpolique's approach involves base64 encoding, which is indeed an elegant and robust solution to the problem of encoding data so it cannot escape from its context.  However, that problem is not the most critical one to solve.  The standard way to solve that problem is through escaping.  And escaping seems to work well enough, in practice, as long as you use the right escaping function for the context where the untrusted data is being inserted: e.g., encodeForHTML for text going into HTML, encodeForURL for data going into a URL context, etc.  The escaping functions are standardized and seem to be pretty reliable.

So it is not clear that Interpolique has a significant advantage over competing approaches.  Its novelty is, arguably, focused on one of the less important aspects of the problem.  It's not clear that Interpolique's special sauce (the base64 encoding part) offers that much advantage to users over other possible approaches.

The most important challenge to tackle, I'd argue, seems to be framework integration and outreach: integrating this stuff into the web application frameworks used by developers, and teaching developers how to use it.  The technology for context-sensitive auto-escaping is now pretty well understood, and the hardest challenge is to get it into widely used frameworks.

Unfortunately, that's not one where I saw a lot of effort from the Interpolique project.  This takes a lot of elbow grease: communicating with the folks who maintain each of the frameworks, articulating the benefits, writing code/patches to integrate the ideas into the frameworks, working with them to devise solutions that are acceptable to them, etc.  I don't know whether the Interpolique project really pushed on that very hard.

Marketing. I don't know whether Interpolique was marketed in a way that ordinary web application developers would understand its benefits.  Its benefits are apparent to security researchers, maybe, but the folks who build web applications, or the folks who maintain web frameworks?  Not so clear.

Kaminsky's slides focus a lot on SQL injection.  While this might make sense from a pedagogical perspective, in retrospect I wonder if it might have been a tactical error from a communication perspective.  There are already "good enough" solutions to SQL injection.  The focus on SQL injection might have triggered a knee-jerk reaction from some developers who were thinking "why do I need this stuff when I feel like I've already got SQL injection reasonably well under control?".  If the potential adopters don't perceive the benefits, they're probably not going to be very receptive to the technology.

Limited market demand. In addition, for most developers, security is a secondary consideration.  It is not so easy to sell a point scheme that addresses a small part of security, when security isn't their primary goal.  Perhaps if you could sell a comprehensive suite that solves all of their potential security problems, developers might become a lot more interested -- but that's not what Interpolique was.

Contributing to this perception that security is not a big deal is that many application developers don't think they have a problem and don't perceive a need for a solution (many of them may be probably fooling themselves, but so it goes).  And of the developers who are aware of XSS, many think they can avoid it by just being careful (that's a dubious proposition, but hey, if they don't perceive the need for a scheme, they ain't gonna buy it).

In any case, it's not clear how you'd make money off something like Interpolique.  It doesn't fall into any of the usual categories.  It's not a tool.  It's not a service.  It's not a comprehensive solution to security.  Rather, it is an idea for how to improve various web frameworks.  To get Interpolique into customers' hands, you'd have to integrate it into those frameworks.  However, those frameworks are usually free.  So I don't see how you'd make money off of it.  How do you monetize a library or an idea?  Where's the business model?  Perhaps the Interpolique folks had a way to make money, but I wonder if part of the lack of success of Interpolique is because there was no clear way to make money off the idea.

Interpolique's contribution: XSS. Let's come back to what Interpolique is good for.  Personally, I believe that its primary contribution is helping to defend against XSS (possibly other injection attacks as well, but most prominently XSS).  It is a pretty clever technique for that -- though it still requires developers to understand how to use it properly, and to remember to use Interpolique everywhere that they interpolate untrusted data into HTML.  Compare to context-sensitive auto-escaping, which happens automatically, doesn't require developer attention, and isn't susceptible to errors of omission where developers forgot to call the escaping function.

Kaminsky's talk does discuss how to use Interpolique to prevent SQL injection, but I suspect that is primarily a pedagogical device.  Interpolique is a general defense against injection attacks, of which SQL injection and XSS are two examples.  SQL injection is easier to understand and simpler to understand than XSS, so it was probably simpler to explain the ideas behind Interpolique in the context of SQL injection than XSS.

Interpolique and SQL injection. As others have said, prepared statements are a "good-enough" solution to SQL injection for practical purposes (there are indeed some cases that are not handled by prepared statements, but they can probably handled by escaping/validation plus careful code audits), so that's not where Interpolique is most useful.

I realize that prepared statements do have some limitations.  One limitation, which Dan Kaminsky explains well, is that the syntax is less than ideal if you are interpolating multiple dynamic values into a long template: it is hard to keep track of which parameter goes where.  However, in practice, this doesn't seem to be a showstopper: developers seem to cope.  Another limitation of prepared statements is that there are rare cases where they cannot be applied, such as dynamic ORDER BY or LIMIT statements.  However, neither of those limitations seems to be a serious problem with prepared statements in practice, so I just don't see Interpolique as being that much better than prepared statements.  And prepared statements have the benefit of being simple, already supported in almost every framework, and already evangelized well to developers.

Why was Kaminsky criticizing escaping?  Here's what's going on.  If you want to escape untrusted data before interpolating it into some string, you need to know how the recipient of the string will be interpreting it, to determine what characters need to be escaped.  If you think the recipient will interpret it as ASCII, but actually the recipient will be treating it as UTF-8, you've got a problem: you probably won't be escaping everything you need to.

This sort of thing has introduced vulnerabilities in PHP/MySQL web applications in the past (here's another example), when they tried to escape untrusted data before interpolating it into a SQL query but didn't realize that the database was using a different character encoding than expected.  This is especially relevant to PHP/MySQL web applications, because there is no integration between the PHP app and the MySQL database: there's no easy way for the PHP code to tell what character encoding the MySQL database will be using on this connection, so there's no easy way to tell what escaping function needs to be used.

So manual escaping is potentially error-prone, since developers sometimes use the wrong escaping function, introducing a security hole.

On the other hand, for XSS prevention, these issues can be addressed given sufficient integration into the web framework.  The framework can tell what character encoding the HTML document is in (because it sends the Content-Encoding: headers, and also because it can parse the HTML document itself), and given sufficient smarts, it can tell what HTML context the untrusted content is being interpolated into (inside a HTML tag?  inside an attribute?  a URL? etc.).  Consequently, given a sufficiently intelligent web framework, the framework can automatically determine what escaping function needs to be used and automatically apply it.  This is the premise behind context-sensitive auto-escaping, and that's how it addresses Kaminsky's criticisms.

The future of this area.  The security technology in this space that has seen the most take-up is context-aware auto-escaping, such as that implemented in Google's ctemplate.  I think this is the most exciting and promising direction for the future.  I don't see much of a business opportunity to make money -- but I do think it could make an appreciable difference towards making web applications more secure and helping developers avoid secure woes.

Context-sensitive auto-escaping involves framework support for defending against XSS automatically, without any extra steps or awareness from the developer.  That goes a step beyond what Interpolique provides.  Consequently, context-sensitive auto-escaping is even better for developers than Interpolique, because in most situations it requires no additional effort from developers: escaping is done automatically for them.  It is better for security, too: escaping is done by default, so you end up with a system that is secure by default.

You could of course combine Interpolique's ideas with context-sensitive auto-escaping (using Interpolique's base64 encoding stuff instead of standard escaping), though the benefits of doing so aren't entirely clear to me.

You can find Interpolique and similar technologies discussed in the following questions: Whitelisting DOM elements to defeat XSS, Escaping JavaScript constants.

Conclusion. I believe that Interpolique was a beautiful, elegant idea, and one that I suspect may have continuing influence on the future of web application development -- even if it is not adopted directly.  At a minimum, it can be understood within the broader context of the move towards context-sensitive auto-escaping and other techniques to help developers avoid common vulnerabilities.


DNS resolution when typing IP address into the browser instead of domain

HTTP and HTTPS are protocols which need the correct hostname in most cases. Often multiple sites are hosted on the same IP address and they can be distinguished only by the name given either in the HTTP-Host header and in case of HTTPS the SNI extension in the TLS handshake. Accessing a site by IP address omits the information about the requested hostname and thus can result in strange error messages or the wrong certificates.

In the specific case of pinnacle.com and the IP address 192.230.70.134: this IP address belongs to Incapsula which is a DDoS mitigation company. The error message you see is from their reverse proxy which forwards the traffic to the protected sites. It cannot handle the hostname 192.230.70.134 given in the HTTP requests since it expects instead the real hostname pinnacle.com. That's what the error message "failed to resolve site from host name" means - it is about finding the target host to the given name and not about DNS resolution.


Do I need to worry about my SSH keys if my system was vulnerable to Heartbleed?

No.  OpenSSH uses a very limited subset of the OpenSSL library, and that subset does not include the code involved in the Heartbleed vulnerability (or any of the other SSL/TLS code, for that matter).

Additionally, the Heartbleed vulnerability doesn't permit an application to read memory outside of its address space, so, for example, a vulnerable web server can't reach out and grab keys from a SSH server.


How does "traceroute over TCP" work, what are the risks, and how can it be mitigated?

All the tracerouting tools rely on the following principle: they send packets with a short life, and wait for ICMP packets reporting the death of these packets. An IP packet has a field called "TTL" (as "Time To Live") which is decremented at each hop; when it reaches 0, the packet dies, and the router on which this happens is supposed to send back a "Time Exceeded" ICMP message. That ICMP message contains the IP address of the said router, thus revealing it.
None of the tools you link to can do anything if some firewall blocks the "Time Exceeded" ICMP packets. However, blocking such packets tend to break the Internet (because hosts adaptively change the TTL in the packets they send in order to cope with long network paths, and they need these ICMP for this process), so, on a general basis, the "Time Exceeded" ICMP packets are not blocked.
What is often blocked, however, is the kind of short-lived packets that traceroute sends. These are the packets with the artificially low TTL. If they are blocked by a firewall, they never get to die "of old age", and thus no Time Exceeded ICMP. For TTL-processing and the "Time Exceeded" ICMP, the type of packet does not matter; this occurs at the IP level. But firewalls also look at packet contents. The goal is to fool firewalls so that they allow the short-lived packet to flow (and then die).
Plain traceroute uses either UDP packets, or ICMP "Echo" packets, both kinds being routinely blocked by (over)zealous sysadmins. tcptraceroute instead uses a TCP "SYN" packet, i.e. the kind of packet that would occur as first step in the TCP "three-way handshake". That kind of packet is not usually blocked by firewall, at least as long as the destination port is "allowed". tcptraceroute will not complete any TCP handshake; it just relies on the ideas that SYN packets are not shot on sight by firewalls.
intrace goes one step further in that it waits for an existing TCP connection (it does so by inspecting all packets, à la tcpdump). When it sees a connection, and the user presses ENTER, intrace will send short-live packets which appear as being part of the observed connection. intrace can do that because it has seen the packets, and so knows the IP addresses, ports and sequence numbers. All relevant firewalls will let these packets pass, since they (obviously) allow the observed TCP connection to proceed. The short-lived packets are adjusted so that they will not disrupt the TCP connection (i.e. they are simple "ACK" packets with no data by themselves, so the destination OS will simply ignore them).

Edit: I notice that I did not answer part of the question. Here it goes: there is no risk. There is nothing to mitigate.
traceroute reveals IP addresses of routers involved in routing packets. IP addresses are not meant to be secret and are rather easy to obtain for attackers through various means (mass scanning comes to mind, but also searching garbage bags for printouts of network maps -- the modern fashion of recycling makes dumpster diving a much easier and cleaner activity than what it used to be). However, a relatively widespread myth is that keeping your addresses secret somehow ensures security. Correspondingly, many sysadmins consider traceroute as a serious breach, to be fixed and blocked as soon as possible. In practice, though, this is all baloney. If revealing a few internal IP addresses is a major issue, then this means that your network is doomed.
Worrying about secrecy of IP addresses is like triggering a major incident response plan because an outsider learned the menu at the company's cafeteria. It is disproportionate. Granted, having precise and extensive knowledge of the network infrastructure can only help attackers; but not in really significant amounts. Keeping IP addresses secret is not worth breaking connectivity through excessive filtering (for instance, blocking the "fragmentation required" ICMP is deadly for any client behind an ADSL+PPPoE link).


Safety of routing a network to a firewall

The only real reason to prevent a network from being routable through a firewall is to make sure it's isolated both from external and internal unauthorized access. It's impossible for someone to hack into a system if there is no physical path for electrons to travel from their position to the target system's position. By unplugging any cables linking the target system(s) to the rest of the world this ensures there is no physical path.

This does however drastically reduce the network's functionality and ease of use since you'd need to be in a specific physical location to interact with any of the target machines. The more secure something is the harder it is to use and the less functionality it has.

If the testing environment doesn't need internet access then the best/easiest thing to do would be to just not connect it to the firewall at all. Just create a testing subnet, put all the servers in it and plug them all into a switch. All the servers will be able to talk to each other and since there is no physical connection to the firewall it's impossible for anyone that doesn't have physical access to the switch or servers to access them.

If the testing environment does need internet access then I would still create a network zone for them (same as above) but in the firewall I would ensure there is a deny rule for any traffic destined for the testing environment. Since any firewall I've seen manufactured in the past 5 years has statefull inspection turned on by default and most of them don't even have an option to disable it, this will allow the servers to reach out to the internet and traffic coming back on that same port will be allowed.

Depending on what exactly they mean by "safe and private" the second scenario is the most likely to be implemented in real practice since almost everything needs to reach the internet for remote management and patches. The first scenario though is the "safest and private-est".


Securing a JavaScript Single Page App with SAML

For the record: In a typical SAML WebSSO flow the IDP wants to take control of the browser to establish or resume a session with the browser. So this approach needs to be tested if it is compatible with your IDP(s). There is another, less popular flow called ECP (Enhanced Client or Proxy) that should be more suitable.

See also:
https://www.codeproject.com/Articles/1248145/How-to-use-SAML-in-an-Angular-JS-Single-Page-Appli


Apart from losing €40, is there any further risk if someone has my prepaid credit card number and home address?

Call the credit card company! They have procedures for this including blocking your credit card and replacing it. You might even be able to get the 40€ back.
There is a lot of articles about this online.

If you knowingly ignore the issue you might be liable for any future damages by fraudulent credit card charges.


How did this site prevent me from creating multiple accounts?

It is not based on IP address and I was able to create two accounts:

Create an account using your gmail account
Go to incognito mode and create an account using 10 minute mail. (There was a 10 minute delay between the two steps)

Mind you, you are gaming the system. It is ethically wrong.


Windows - service account default certificate store

Turns out that the intermediate certificate (Thawte SGC CA - G2) needs to be downloaded off of Thawte's site. And the reason why the service account couldn't establish the trust is because it's not allowed to download the certificate.


Is my Windows phone protected from attacks that reveal list of ssids it knows about?

This is what the WiFi Pineapple abuses.

When you walk around with your digital device with WiFi enabled and connect automatically set to on, everytime your device detects a wireless signal it will send out probe requests to see if the SSIDs match.

With a regular Access Point nothing happens, meaning the AP just discards the probe, but with the WiFi Pineapple or a similar device, it will say yes, I am this network. Connect to me, and emails and applications that auto-update will do so.

If this malicious AP then runs wireshark, or another packet sniffer, and a version of SSLstrip (or something similar), it will sniff credentials. On the Pineapple this feature is called Karma. If a connection is established you get the MAC address of the device.

This problem has become quite known these days, and methods to hinder this simple MITM attack are put in place by forcing the clients browser to use HSTS layers. This means that if the client will send a request to the server over HTTP, the server will respond that it only accepts HTTPS and will force the client to use it. You can find more info on the Pineapple at Pineapple Uni.

Not all sites use HSTS yet, so the Karma function will still work on some websites, but either way, the Pineapple, or a similar device, will sniff the SSID.


Offensive Security refuses to give details on the number of their certificates' holders or on the passing rate as they "don't want to unnecessarily encourage or discourage people"


Nessus: Host Discovery Scan finds no host

Check on both vms, on network configurations, if both are on the same virtual network and the virtual network card is connected.

Also do some simple connectivity tests like ping and nmap. If nothing works, test if your machine have access to any of the virtual machines and try to sniff the traffic there.

If there is no tcpdump or any other sniffer installed on metasploitable, with I presume that doesn't have any, you can download de .deb file and upload it. Install with dpkg -i tcpdump.deb

If nothing above works, and the packet capture show no packets, take a look into the kernel logs with dmesg, to see if the network card was recognised by the operating system, and check lspci to analyse if the network card is there.


How to secure usb data storage of Android phones?

Actually, the maximum number of combinations an Android pass-pattern can have, given that the user must choose a pattern of at least four unique dots and can use up to all nine, is 9!+8!+7!+6!+5!+4! = 362880+40320+5040+720+120+24 = 409104 combinations, about 2^18.6. Child's play for a computer, made marginally more difficult by its being a UI-based entry scheme, and the cooldown period most Android phones have after 3 incorrect tries.

You can "lock" the SD card/SIM with a PIN that only allows it to be used in that phone by someone that has properly unlocked the phone. I'm not sure how easy/hard it is to break that layer; I would hope it's implemented via a decently-secure level of encryption.

In the worst case, Android phones support an option that wipes all data after 3-5 failed unlock attempts; if the data on the phone means more to an attacker than you, do this. Combined with encrypted phone and SD storage, this is about as safe as your phone's data will get. Most phone manufacturers and cell carriers provide offline backups; if your phone were to get wiped, you can simply restore the backup (restoration requires multi-factor authentication by providing a code they either gave you or that you gave them), and most of the things that make your phone yours are back in place. Other companies support remote wiping and/or remote bricking; report the phone as lost and the cell carrier will order the phone to factory reset and wipe the SD card, and/or to brick itself. Of course, the phone has to receive that command; you can work around it as a thief by quickly getting the battery out of the phone or putting it in Airplane mode, and then doing further work with it in a Farraday cage shielded from cell signal (It's really not as farfetched as it sounds, but it only works if the data the thief is after is on the phone itself and not somewhere the phone would give them access to).


Use truecrypt to make data unrecoverable

If you want to destroy all data on your disk, why not use a file shredding tool? There are plenty of them available, and it is a lot easier solution that creating a truecrypt volume and then deleting that volume.

I also don't know how truecrypt initializes volumes. It is possible that truecrypt writes random data to the volume only once, while file shredding software can (and should) do multiple passes, making the chance of recovering data even smaller.


Does changing one's last name offer some protection against identity theft

It sounds like an idea, but there is a few things that I want to point out here,

Changing a last name officially takes a while

It really does take a while, please see  this link. It also depends, if you have like a thousand employees, would you make all of them fill out the form and wait for a response from the SSA? Would it be convenient? You should answer that question yourself.

Second and most important, social engineering attacks

After you've done the first process, it comes to securing the last names from the attackers since they already have all of the information about the workers but the last names.

It is very easy to get the last names under this circumstance

When your workers are out to get a drink, the attackers could act like a friend, start a conversation, ask to see their ID that they don't believe their age, and they could see the new last name there. Or the easiest, just ask for their full name.

They could steal their wallets,

follow them home, hack their personal pcs in their houses and know what they're all up to from there.

There is also tons of  social engineering attacks that could be made to know the last name of a person. It is easy.

So as an answer, no it is not worth it but it may depend. You could change the last name of a CTO or some high ranked worker, and tell him about the situation, so that he is very very very much careful on not giving away any info to a stranger. He should not be pulling out his ID in public. That's how it could be reasonable from my point of view.


What reliable methods are available for tracing the source of an ARP poisoning attack?

According to my research on the subject, and running tests there are no quick fixes for tracking the source individual perpetrating this type of attack because of the nature of it. Meaning tracking, but not filtering/blocking. The attack method itself is basically easy to do compared to the scale of other types of attacks out there due to fundamental flaws in network hardware. There are however methods of blocking or tracking (in part) and ways to narrow down the search for an attacker.

One such tool called arpwatch (http://www.securityfocus.com/tools/142) that scans for changes in IP and MAC address then delivers an alert when found. There is a SUSE article on using the tool here: https://www.suse.com/communities/conversations/detecting-arp-poisoning-attacks/

The check into DHCP Snooping and DAI (Dynamic ARP Inspection): http://packetlife.net/blog/2010/aug/18/dhcp-snooping-and-dynamic-arp-inspection/

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_0_4_s_v_1_3/security/configuration/guide/n1000v_security/n1000v_security_12dhcpsnoop.html

Izam is right, it is much easier to detect ARP poisoning than it is to target the attacker. The methods used most often find it when it occurs, or are focused on prevention. Wireshark describes a method of finding a starting point 'for investigation': http://searchsecurity.techtarget.com/video/How-to-use-Wireshark-to-detect-and-prevent-ARP-spoofing

ArpPoisoning.com offers a couple of scripts you run when you log into a server you have concern may be a target. http://www.arppoisoning.com/best-practices-for-defending-against-arp-poisoning-2/ One for linux: https://github.com/alan-reed/ARP-Defense and one for Windows based machines: https://github.com/alan-reed/ARP-Defense/blob/master/defendAPR.bat

The 2 scripts attempt to track the ARP table and compare it live as you are connected, and attempt to repair the ARP table as it is happening.

Another step would be to attempt triangulation (or trilateration) to target the attacker's physical location between multiple access points.

If you have multiple access points, then you have the opportunity when you find the one that is getting the highest level of ARP request traffic, and then by checking the signal strength pinpoint the location of an originating machine.

A security application by Aruba Networks uses triangulation to attempt to locate problems on the network as 'interference sources'. Interestingly enough, they have the same trick in reverse, using ARP poisoning as a defensive weapon: if an 'interference source' is detected it attempts to poison the ARP of the port of the switch used by it and kill its access to the network (page 19 here): http://www.arubanetworks.com/pdf/technology/TB_ProtectTheAir.pdf

Granted I do not have access to a network protected by this automated and multifaceted defensive structure but I would be interested to see how well and how quickly it takes out threats like ARP attacks. Being that it defends against specific points as they are compromised, an assertion could be made that it would give a good general direction in the real environment to look for a physical attacker.

For small networks, it would be better to filter out bad ARP requests and set fixed IP & MAC connections where possible. Then it is much easier to track with fewer connections.


Limiting information disclosed by server

It most likely doesn't matter what your server tells the client, the IP address used to communicate with your virtual azure server is owned by Microsoft and most likely labeled as being used for their cloud offering. You have no influence on this, but it is not a security risk either.


Driftnet not picking any images from the target

It's because you can only browse Google over https only and not http.Even if you force http, the response for that request will be a redirect to https.Along with the arpspoof, you will have to use a tool which will be a middle man doing the ssl handshake with the target's browser and Google. MITMproxy works great.There is still a catch though, the target's browser will flag the connection to be insecure, because MITMproxy will be using its own selfsigned certificate for handshake.Beacuse your other end  is Google, target won't be able to add an exception in the browser and continue browsing because HSTS is set.To force the browsing, you will have to add MITMproxy's cert to the trustable root certificates manually in the browser.

Mitmproxy

How to use MITMPROXY

Edit: If you are seeing this problem for 'only' http connection too, check the Network settings for your bridge adapter in VirtualBox.You should set Promiscuous Mode to Allow All.


How can I be sure that I'm downloading over SSL?

If you are trying to write code for downloading data over TLS(SSL) you should consider if you know which hosts you are downloading from and use a technique caled certificate pinning.

Cert. pinning is hard-coding the certificate of the server you are connecting to in your code and only accepting the connection if it is made over TLS using the expected certificate. OWASP explains the concept here: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

But basically it comes down to you explicitly verifying the different details of the connection you are setting up. More information about the framework and scenario would help.


How many security holes were discovered in the original version of Windows XP?

In total, across all service packs, there were 721 KNOWN vulnerabilities.


Blindly downloading a git repo: specifically, generating .pack files

A first step would be to simply try to git clone the URL ending in .git. Depending on the remote repository's configuration, the git client may be able to create a copy on its own!

If not, you may be able to obtain a list of packs at the relative URL:

.git/objects/info/packs

If the remote repository contains packs, they will be listed in the format:

P pack-c3499c2729730a7f807efb8676a92dcb6f8a3f8f.pack

which will indicate that a pack exists at:

.git/objects/pack/c3499c2729730a7f807efb8676a92dcb6f8a3f8f.pack

Two other paths worth investigating are:

.git/config -- this may contain sensitive configuration information, such as the URL and username that were used to clone the repository
.git/info/refs -- may contain names of branches or tags that you weren't otherwise aware of


There is no right or wrong answer. If you implement a more aggressive lockout policy then you will be more secure and you will degrade your user experience.

You have to assess where the right balance is for yourself, based on your application's requirements, your knowledge of your user base, the value of the assets you are protecting, your threat model, your risk analysis results, etc. etc.


Should the password field be cleared after an unsuccessful login attempt?

It should be cleared.

It's not that uncommon a situation where a user enters the password, hits "log in", and wanders off for a bit, doing other things. It has certainly happened to me where I have attempted to log in to GMail, and come to know of the failed login an hour later. There are also systems (sudo apt-get -y install comes to mind, though in this case the failed password attempt isn't retrievable) where you need to just authenticate and then forget about it --

In the GMail situation listed above, someone could easily get the plaintext password (well, the typo'd version, but usually it's easy to fix that) if I got up from my computer in that hour.

  if an attacker has access to my computer there are more efficient ways of harming me

There's much more havoc that can be wreaked if an attacker knows the password than in the case where the attacker is just logged in, usually.

However, this really depends on the system. For a desktop login screen, it doesn't matter much as long as the password field isn't copyable. For online services, it matters a lot more.


You could route your traffic through Tor. If you get blocked, you can simply change to a new virtual circuit with a different exit node. You could achieve this by integrating a Tor client library into your scripts, e.g. libtor. You could also set your system's HTTP proxy to a local SOCKS proxy capable of connecting to Tor. Some good options have been discussed on SuperUser.SE. This could fail if the servers can detect and block connections from the Tor network.

Other than that, you could try routing your traffic through a plain old HTTP proxy or VPN. Even this could fail if your script has a particular user agent fingerprint that can be identified and blocked.

You could also access pages through Google's internet cache or the Internet Archive. You may be able to cleverly use Google queries to do your scraping for you, sidestepping your concerns entirely.

Any attempt to evade detection will slow your crawling, possibly a lot. Tor will be very slow. Furthermore, this is arguably a malicious use of Tor. However, this method could be ethical in the case of a legal penetration test in which you attempt to simulate attackers.

Ultimately, you aren't engaging in a penetration test, so evading detection is not really necessary. If you're worried about being blocked, you could talk to the site owners and seek their permission to crawl the website. Perhaps they don't care, as is usually the case with publicly available websites.


Does Mozilla's new "Facebook Container" have any advantages over uBlock Origin?

To understand the differences, we have to look at the different goals of the two.
Or in other words: What do they want to do? What do they do? And how does it affect you as an end user?
In this answer I will speak of Firefox's Multi Account Containers and Firefox's Facebook Container as pretty much the same thing, because - as far as I understand it - technologically they are.

What do they want to do?
uBlock
The creators of uBlock tell us here:

uBlock Origin (or uBlock₀) is not an ad blocker; it's a general-purpose blocker. [...] Ads, "unintrusive" or not, are just the visible portions of privacy-invading apparatus entering your browser when you visit most sites nowadays. uBlock₀'s main goal is to help users neutralize such privacy-invading apparatus — in a way that welcomes those users who don't wish to use more technical, involved means [...].

Their emphasis
Firefox Containers
Firefox says this about their addons:

Firefox Multi-Account Containers lets you keep parts of your online life separated into color-coded tabs that preserve your privacy.

and

Rather than stop using a service you find valuable, we think you should have tools to limit what data others can obtain.

This sounds very similar, but the differences are in the details.
uBlock is focused on privacy on a broad scale and users sometimes have to hazard the consequences -> buttons can stop functioning, sites can break etc.
The Firefox extensions are the parent-version of a neat tool to ensure some privacy. You can still use all services. There can be some collateral damage, but rarely for the typical user. And it's all color-coded, weeeee!

What do they do?
uBlock
uBlock Origin blocks these three types of annoyances: ads, trackers and sometimes malware sites, but can do a lot more. It has a pretty wide range for such a lean tool, but you have to be somewhat experienced to make use of the more interesting options like medium and hard mode. And if you do, sites will regularly start to break if you browse like most of the regular internet users.
If you take a look at the documentation I linked to, you will see what uBlock can do "under the hood".
Note: a lot of blocking by uBlock requires filter lists. The maintenance of theses lists is very difficult and tiresome and is done by a lot of nice people on the interwebz. Because they do it for free, sometimes trackers will not get blocked, because they are not on the list you are using. IMO that is not all too problematic, because the problem you as a user have stems from forming profiles, not from creating single points of information. If the contributors update the lists properly and you regularly update your filter list it is likely that the next time you visit a site with that tracker, it will not track you.
Firefox Containers
In the description of Firefox Multi-Account Containers, we find the following:

Each Container stores cookies separately, so you can log into the same site with different accounts and online trackers can’t easily connect the browsing.

and under the description for Facebook Container

What does Facebook Container NOT protect against?
This extension focuses on limiting Facebook tracking, but other ad networks may try to correlate your Facebook activities with your regular browsing. [...]

The big thing we can note: Firefox Multi-Account Containers neither block ads nor trackers. But this isn't what they were built for. They were built for separation or containerization. A lot of data is accesible for sites you visit across tabs - for instance: cookies.
Containered tabs - this is what we are looking at here - prevent this.

How does it affect you as an end user?
You can easily use both addons. I would definitely recommend uBlock (go for the hard mode). There are some restrictions that containerization brings to the table that can be helpful. I am not too knowledgeable about the inner workings of it though.
Conclusion: The two addons are very different, but that is very much okay, because they have different goals and I would say different audiences with different privacy needs.


Most DNS servers support views -- the idea that different data will be presented to clients depending on their IP address.  ACLs per IP address are also frequently supported for individual functions (e.g. BIND's allow-query, allow-transfer and allow-recursion clauses).

It's possible your IP is not allowed to query a specific server (or zone), that the view you see doesn't contain the zone, or that you are not allowed to make recursive queries.


Is an exploit that exposes the balance of any account in the bank a high risk exploit?

This is definitely a leak of sensitive information. Privacy demands that as an account holder my bank balance is not disclosed to random individuals. Some people might not be bothered by such a disclosure, but most will consider it a breach of their privacy.

  What is the level of this exploit (risk, medium, low)?

This is subjective to the environment but I would say in this case the risk to privacy is 'high'.

  is it ethical to ask for a prize or money before telling them what is
  the problem?

Answer to this is, again, subjective. Do they have a bug bounty program where they are offering rewards for such disclosures? If yes, then it is ethical for you to report the issue and claim the reward. If they do not have a bounty program, I would write an email to their IT or security team with details of your findings without expecting anything but a 'thank you' (which you might or might not get).

In case you receive no response from them and they do not patch the vulnerability, you might want to go for full disclosure in a public forum after waiting a certain period of time.


I'm not aware of any publicly available toolsets for this at the moment, but there's been a couple of interesting white-papers and postings recently on the general security dangers of cursors

Two from David Litchfield here and here

and an interesting blog posting from Pete Finnigan here


Do any routers report a brute force attempt?

Short of locking out the device or incurring some time-based delay, there is no harm in brute forcing the password. You may also want to scan it with a vulnerability scanner to see if there are any disclosed vulnerabilities which you can exploit to gain access to the router.

As long as you own the device and have permission to attack it, feel free to BF till your hearts content.


I've discovered a vulnerability which can reveal personal information for multiple websites. How to go about it?

Unless they have some form of bug bounty type program, you are putting yourself at risk by disclosing to organizations that haven’t hired you. The organization can turn around and say “You’re hacking us, this is proof. We’re suing you.” I have had to fight senior leadership at past jobs to not take that course of action. Or similar minded BS because they see it more as an attack against them. They think it’s more secure to attack you then disclose that information.

If these are smaller organizations, there is less of a risk of this. Generally, your information will go to the people that will care and want to fix it first. They will generally (not always) be thankful for the feedback and want to back it better. At larger organizations it will go to legal first and they decide how to respond before it would go to the people that would potentially fix it.

If you choose to disclose it, take every possible precaution to ensure they can’t track it back to you. Personally, I wouldn’t disclose this unless they have a bug bounty type program. It’s not worth risking your career for. That may seem contrary to what we should do as security professionals. Regardless of whether you would win or lose in court, your reputation will take a hit and employers, as well as your current employer, may think twice. The organizations may go after your current employer as well. How would they respond to that?


How significant is the risk in having someone email/IM an htpasswd hash?

By default,  the htpasswd utility tends to use an Apache-specific hashing password called "apr1" and documented here. It seems to be a custom construction that invokes MD5 1000 times. Assuming that there is no structural weakness in that construction, the attacker can still try out passwords at a rather fast rate. As documented here, an AMD R9 290X GPU is be able to compute about 11.5 billions of MD5 per second. Since each password try requires a thousand MD5 invocations, the attacker should be able to try 11.5 millions of passwords per second. This is quite fast, and one has to assume that a "normal user password" won't last very long.

Even a rather strong 44-bit entropy password will fall within a week of computations, with an attacker using a single off-the-shelf GPU.

Function identification is not hard since it is written in the hash string itself (e.g. it begins with $apr1$).

Personally, I'd use the phone. As @André suggests, PGP is also usable, provided that PGP is installed. Another option is to open an SSH-based shell account (this requires obtaining a copy of the SSH public key of the user) and storing the password in a file on that account (or the user pushes his htpasswd file there).

Emails may be fine if you can control the whereabouts of the email, which is hard in all generality, but can be made much easier in some cases. Namely, have the user send the email from his gmail account to your gmail account; presumably, emails sent from gmail to gmail don't travel unprotected over the Internet. However, since there is no security whatsoever in the email protocols, such an assumption cannot be made for just any email server.

(As a rule, it is better to assume that any attacker who bothers reading your emails knows quite a bit about what you do and what exchanged passwords are for -- after all, he reads your emails.)


Do I correctly understand how CORS proxy works?

If you are trying to defeat CORS you are actively trying to create insecurity and vulnerability for your end users. CORS was not created because we delight in creating unnecessary hurdles to make developers' lives miserable. (We do, but that's not why we did it this time!) CORS helps protect end users. It's super important and it is the way of the future. Here's a really good article explaining CORS. I would urge you not to look for ways to bypass it and work around it. Look for ways to get your web site working with it.

If you build a web site that depends on some proxying site in order to work, but you're not paying that proxy and you're not running that proxy, your whole web site might just stop working one day because that proxy goes offline. Or the user might have trouble reaching the proxy from their network location while they have no trouble reaching your web app from their location. The net result to your end user is that your app looks like it doesn't work, when it's really a problem with them reaching that proxy.

It's a sloppy workaround that bypasses a really useful security control. I'd urge you to rethink this approach.

To answer your question, yes, your javascript or XHR or JSON payloads will have to pass through the proxy. And that's the IP address you're going to see for some requests. It will hinder your ability to analyse who is visiting your site, expecially if anyone is doing something malicious.


Is there a combination program that will generate a dictionary from a predefined list of words and numbers in specific order?

What you are trying to accomplish is called password mutations, or definition rule-sets. I would use John the Ripper for this (JTR), not because i hate crunch, but just because i've been using it a long time and i can give you specific examples for it.

let say you have a word list, containing the various different base strings you wish to test.

cat
fcw
cfd
etc...

and you wish to try different combinations of them, maybe some added anomalies for completeness sake. well we can do that with a configuration file. (john defines this as rules, but its all the same)

basic password cracking looks ike this:

john mypasswordsdump --wordlist=stringlist.txt

this will test each password in stringlist against the hashes in the dump. simple. now we add the extra element.

in /etc/john.conf (im not sure where it is in the windows version but im sure its not hard to find) you may or may not see something like this:

[List.Rules:<somenamehere>]

these are the declaration of rule sets. and you can add some pretty nifty functons here. a wide variety in fact.  is important because this is how you tell john in the command line what rules to use against your passwords.

so for the sake of example we will use [List.Rules:testrules]

now there are some great resources for building these rules:

http://www.openwall.com/john/doc/RULES.shtml
http://juggernaut.wikidot.com/jtr#toc15

just as examples. but lets try something easy.

[List.Rules:testrules]
cAz"515"

running this is john like this:

john mypassworddump --wordlist=stringlist.txt --rules=testrules

will result in the first letter being capitalized, the rest of the word printing noramlly, and then appending 515 to the end and then trying each of those passwords against your hashes:

Cat515
Fcw515
Cfd515
etc...

of course the more complex you make the rules, the more diverse the passwords get and the more tries JTR will have to do.

instead of straight "515" we write [0-9], this will append a single digit to the end of each word, from 0 to 9 and moving on to the next one.

in this way many sorts of mutation can be defined. its a lot of fun!


Mail delivery is done hop by hop and not end to end. This means a typical sender in a company delivers its mail via SMTP (or some proprietary protocol) to the mail server which then delivers it via SMTP to the next mail server etc until the final mail server gets the mail and stores it. In some cases this can involves many hops which not only include simple mail transfer agents but also mail filters, firewalls or similar.

SSL can be done at each of the different delivery steps or it can be omitted. If it is done it needs to be support by both the sending MTA (as SSL client) and the receiving MTA (as SSL server). gmail actually does not now about all these steps. The red lock is only shown if TLS was not used on the last step of delivery, no matter if the previous delivery steps used TLS. And it will not be shown if the last step used TLS but some previous steps did not.


Password shows as plaintext via burp suite interception for HTTPS request, is it an issue?

It's not a vulnerability.

Since the page transmits the password via HTTPS, it's encrypted before being sent on the network.

You allowed Burp to decrypt any encrypted traffic by adding their certificate into your trusted certificates store: that's the only reason why Burp is able to perform a man-in-the-middle attack and see the password in plaintext format.

Anyone else will only see encrypted traffic, and won't even be able to tell if a password is being transmitted.


Lets get some ground rules out of the way.   SHA512 isn't an encryption function,  its a hash function.  PBKDF2 (Assuming you are using the newer 2nd variant...) isn't a hash function or an encryption function,  its a way of using a hash function and is commonly used to generate the key for an block cipher or stream cipher.

In most situations I don't think PBKDF2 is very helpful.  The problem being that if you use a hash function like SHA512 with PBKDF2 then an attacker can still use an FPGA or GPU cluster.  Bcrypt is more difficult to attack using these technologies than PBKDF2+SHA512,  regardless of the number of rounds you choose to use with PBKDF2.   You could use PBKDF2+Bcrypt,  and that is not a bad choice, however I still think that scrypt is a better choice because both CPU usage and memory usage are variable,  where as with PBKDF2 only CPU usage and the hash function used is variable.

Up next your IV design:

Use the first x bits of the DerivedKey as the AES SecretKey
Use the second x bits of the DerivedKey as the AES RandomIV

Ok,  so based on this design I would conclude you have no idea what an IV is or why its used.   So the point of an IV is that at no point will you encrypt the same message with the same key+iv.  Your proposed design is in clear violation of CWE-329.  The attacker can know the IV,  that doesn't matter,  but it must always be random.  There are a few reasons why,  and I suggest picking up a copy of Practical Cryptography because it has an entire chapter devoted to this topic.

Also CBC mode isn't authenticated,  I am a fan of OMAC1 mode.


The documentation (especially the Manage Docker as a non-root user part of Post-installation steps for Linux) is really clear on this:

  Warning: The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

Creating the docker group by itself does not imply a security risk (which is what you have been asking). But adding a user to this group may increase your attack surface (which is what you probably wanted to ask). The actual security risk depends on your threat model.


Certificates are validated locally. However, the client may contact the CA repository if some pieces of information are missing. For example, if an intermediate CA certificate is missing from the local store and the web server didn't return it during the handshake, the client may download the missing certificate from the CA repository. Additionally, the client can check certificate revocation by contacting the CA via OCSP or by downloding a CRL from the CA repository when no up-to-date revocation information is stored in the local cache.

Signature and chain validations are always performed locally.


Network security question (NLB and 2-way TLS)

If "Sample Network" is a trusted network, and access is limited to machines (and possibly people) that are fully trusted (such as in a DMZ), then it would be better to terminate TLS at  the load balancer, and have plain HTTP between the LB and the web server.

Is there any requirement to have HTTPS between the load balancer and the web server - what advantage does it give?


Can a hacker see me changing my router password?

If the attacker has managed to either (a) modify the software running on the router, or (b) infect the computer used to change the password, then yes, the attacker will be able to steal the new password you set.

If you suspect that both the router and the computer has been hacked, I would recommend the following:

Disconnect both the router and computer from the internet and each other.
Do a factory reset on the router and do a complete wipe and reinstall of the OS on the computer.
Connect the computer and router and reconfigure the router.


What can be the risks of opening mdb files in windows using microsoft access?

I do not think Firefox is telling you that ".mdb" files can harm your computer, but rather Microsoft Access is telling you this warning message.  A ".mdb" file is a MS Access 2007 and earlier type of Access database file.  Every file that is downloaded from the internet and opened by any MS Office application will give a warning when opening the file.

The reason being that, in many MS Office applications you can insert something called "macros" in an MS Office file.  Macros are short programs that are written usually in VB Script (Visual Basic), and their intended purpose is to do minute tasks.  Since malicious software can also be created from VB, it is possible for a macro in an MS Office file to be malicious code.

For a user that will be using the macros for themselves later, it would not be concern as they themselves were the original creators of the macros.  However, trouble comes when opening files from the internet, as the file may contain malicious macros that may infect the computer.  Thus, the reason why such warning messages come when opening MS Office files from the internet, with a MS Office application.


First let's layout the different definitions:

TPM is a piece of Hardware specifically created to do crypto calculation with. It is physically isolated from the rest of the processing system and is often a separated IC on the mainboard to be so.
TEE is an area on the chipset that works like a TPM, but is not physically isolated from the rest of the chip.
SE is a tamper-resistant secrets store, much like a smart-card or SIM-card. Its main purpose is to store cryptographic secrets in such a way that illicit use is hard or impossible to do. An example of this technology in major use is the EMV chip on payment cards.

We can clearly see when comparing the definitions that these 3 items are different,  but share a common goal. The difference between a TPM and a TEE is mainly in how it is implemented (purely hardware, or hardware and software combo). The SE has a different function that can be part of the function of a TPM and/or a TEE, by being a safe place to store cryptographic secrets.