Harden against privilege escalation in Microservices Please consider the following scenario.

The system has a set of business owners (i.e. users of the system)
Each business owner is mapped to a set of customers
The business owners login to the system in order to manage their customers.

The business owners will select a single customer first, and from there onward his session is bound that selected customer.

I have a set of microservices, each requires a Customer-ID for processing. i.e.

Microservice A exposes GET /resource-a/{customer-id}
Microservice B exposes POST /resource-b/{customer-id}
etc.

The Customer-Id is considered to be a sensitive information - so that it is in encrypted form.

However it's still vulnerable to privilege-escalation. i.e. one business owner may mistakenly share the encrypted customer-id through bookmarks etc. so that a business owner may access details of customers who aren't mapped to him. (not exactly privilege-escalation?)

I want to avoid server-side authorization of customer-id against business owner because it is known to be a slow operation and and 90% of the APIs will have to repeat this authorization process
All the microservices are stateless, so that it's not possible to encrypt the Customer-Id with the session-id as the key (since no stateful microservices/ session)
Also I don't think it's a good idea to do this authorization at the gateway since it's not intended to perform such business logic.

How can I prevent privilege escalation in this situation?

Considering that you don't want to do this on server-side, I see only two other possibilities:

Go with security through obscurity, and never expose the Customer-Id on user facing (any action that make it show up in address bar, UI, browser history etc.). This won't patch your problem and will not protect you against a dedicated attacker. Though it might work at certain degree.
Use Stateless Self-Contained Tokens (eg. JWT) for generating the user session. And store all the customer-id's that are bound to that user on the token itself. Then, when you verify the session token server-side, you will also get authorization at same time. This would not cost in performance at all. Though, it might work as a solution only as far as you wont have a lot a customer-ids bound to a user (obviously you don't want the whole DB in the token).


OSSEC New Install: Scan and analyse full log? When OSSEC is installed and started, it starts analyzing configured logs starting the date it was installed. Is there a way to have it scan and analyze the full logs?

I'm not certain it will automatically, as its core purpose is real-time alerting and active response.

In saying that, you can run manual log analysis on any log file. The instructions at http://ossec-docs.readthedocs.org/en/latest/programs/ossec-logtest.html give guidance on configuring log analysis. You just need to provide the name of the file to be monitored.  For example:

# cat /var/log/access.log | /var/ossec/bin/ossec-logtest -a


Is 100% anonymity possible with Tor under certain circumstances? Tor has guidelines that define a set of rules/techniques to assure anonymity. Some examples are browsing in small window mode so your screen resolution can't be detected, using HTTPS everywhere, and never using third-party plugins and blocking parts of Javascript. Since Tor encrypts data, let's assume that someone uses it to be a repeat-offender (harassment, bullying, DDOS/DOS attacks/etc.), is it possible that said person could possibly be impossible to track among any means possible, even given their annoying, disruptive and destructive nature? I mean nothing that would cause a major red flag (terrorism, etc.), but that can otherwise delay, impede and ruin/torment others through anonymity?

I ask because I've heard of some online communities that say they have no options but to deal with repeat-offending trolls no matter what, and the site cannot stop them because of Tor/proxies/VPN/etc., and they are deliberating harassing, impeding and otherwise being destructive and toxic to communities.

Is it true that, given some habitual measures of abuse, you can sometimes be truly anonymous?

ToR and associated products (e.g. Tails) provide a technological capability which will, if used consistently, allow certain actions to be taken online without any easy way to track them back to the person executing them.

So it's likely that the weak point in an anonymous browsing setup will be the person operating it.  Good Operational Security (OpSec) practice is difficult to achieve for most people, and there are a wide number of actions which could reveal information about the user behind the system.

Good OpSec requires a lot of discipline (e.g. never logging in without using ToR no matter how urgent it is, never mentioning any aspects of your real life whilst trying to be anonymous online and lots more)

So the most likely way that a troll or abuser would be unmasked would be that they slip up whilst trying to be anonymous, although there they'd only get caught if someone is watching for it and also if they haven't done anything illegal their OpSec slip-up may have limited consequences.

One option that some sites take to address this kind of problem is just block known ToR exit nodes and other well known anonymous proxies from connecting to their systems.  Depending on the user-base this may or may not be acceptable.  Obviously people have good reasons to want to be anonymous online (sometimes to avoid abusive people) so blocking ToR isn't appropriate for a lot of sites.


Security for KeePass Emergencey Sheet KeePass just introduced the concept of an emergency sheet that can be shared with trusted users. This question might go beyond the scope of this site, but suppose you printed one of these sheets, how would you store it?

I found this IS page, but I'm talking about the average house and the average person.

Suppose I printed the emergency sheet and allowed only my spouse or trusted member of my family access, what would be the ideal way of storing it to prevent unauthorized access? My guess would be a strong safe, I doubt a safety deposit box (my guess, anyone that can access your SDB, probably knows where you live).

After choosing secure storage for your sheet, how would you handle password policy, or changing your passwords periodically? You would have to print a new sheet, and properly destroy the old one.

Again, this question might go beyond the scope of this site, but before it's gets closed or put on hold, what are your thoughts?

The answer lies in the question of what is the risks and threats?

A regular person, who doesn't have any specific threat to their safety/security likely is well served by having a fire and water-resistant personal safe (1-2 hour fire rating should cover most home fires).  This is where most people store a few items, like some emergency cash, passports, birth certificate, adoption papers, will, password sheet, etc.  A backup copy can be put in a SDB.

In this day, many people have 100-200 passwords for all of the sites we visit.  I think my list has about 300, since I use a long, complex, and random password, mother's maiden name, childhood friend, and those other reset questions - unique for every site.

I've had jobs where the ROOT passwords were all kept in a physical safe that was heavy TRTL 30x6, bolted down, in a locked room, locked floor, locked building.  That was policy.

In short, personally, I think that putting in the home's safe and SDB is a good idea for family COOP.

(Note.  If you are the type of person who would be the victim on a tv show, you might consider stronger measures, like a TRTL 24x6, armed guard, etc.)


Is it possible to prove the content of a file hasn't changed since certain date? Today I make an archive file. Later I might want to send the archive file to somebody else, but when I send it, I want to be able to prove to the other person that I haven't changed anything in it after today.
Knowing that computer- and serverdates may be spoofed, can I do anything myself to assure this? Like including something or anything.

I've been thinking about hashes, but that doesn't seem to fix the content in time. Only when I would have it registered at a notary, but that would be a bit oversized solution :-). And including the headlines of todays news would only prove it's NOT unaltered since yesterday.

Can this be done, or is there any objective reasoning why this would not be possible?

While you cannot mathematically prove that a document was unchanged since a certain time, you can use a Trusted Timestamp Service to provide signed evidence that you haven’t tampered with it since the time you submitted it to be signed.


Authenticating users on a second website with a one time querystring ID - is this secure? We need to authenticate users on a second website that are 'sent' from a first website without having to login again.

The way we plan to do this is for a single use ID to be sent to the second site in a querystring. Once received the second site contacts the first webserver via a secure web service, which says 'yes' or 'no' whether the code is genuine and they can login.

All communication will be via HTTPS.

Are there big security holes in this that we have overlooked? Is this secure?

Thanks.

It is not the best way.

If there are any third party resources or links on the target site, the query string in the URL could be revealed to them in the referer header.

Also, query string parameters are logged by default on the server, meaning an unscrupulous admin may be able to gain access to sessions. Same applies for any proxy servers en route that undertake application level inspections that have  a trusted SSL/TLS cert installed.

A more minor point is that it is visible on screen so a "shoulder surfer" or a camera could pick up the token.

In short, the POST method is much more secure because it does not have the above flaws.


Concerns of data being on the cloud Would you prefer a private cloud for your data or a public one?

Who takes care of financial liability in case of any breach?

Do companies still keep the most critical within their data centers, but would not mind hosting their other non-critical data on the cloud?

Is the strategy to wait and watch? Or would you take take the risk?

Your company takes on any and all risks associated with any breaches.  You'll find that by signing up for public cloud environments, you'll have to sign a document accepting that provider's Terms of Service.  Among those TOS will be something along the lines of a full waiver of any liability on the part of the provider.

Even in the "compliant" (as in PCI/FISMA/ETC) cloud environments, you'll see that same sort of language, even though in those cases the providers have gone through (hopefully) some pretty significant auditing of their policies, procedures, and security measures.

Nobody keeps critical data in a public cloud.  Until hypervisors are guaranteed to be bulletproof (and they're not at this time), I would never trust a public cloud with any data that required any kind of compliance or regulatory oversight, like Personally Identifiable Information, financial data, medical records, etc.

With a private cloud, you are at least relatively assured that the other users (VMs) in the environment aren't trying to break through the hypervisor to get to your data.  You have full control of the hardware (full stack, not just the servers), hypervisor, VM images, access controls, and auditing and logging.

One thing we're starting to see more of is hybrid environments.  Where the critical data is maintained in a private environment, while portions of the stack that don't host critical data might be in the cloud.

For example, keep your SAN, and your DB servers in the private space, but keep your webservers in cloud, where you can use the elasticity of cloud computing to dynamically grow and shrink the number of servers running at any given time to accommodate changing work loads.  Or maybe just the webservers that serve static, non-PII, content are in the cloud, but the servers people log into are in the private space.

There are a number of ways to leverage the benefits of cloud computing without compromising your security.  People are doing it today.  Cloud computing is arguably the fastest growing segment of IT, outside of IT Security.


Why are PGP signatures not more widely used as an authentication method? Example:

Bob generates a key pair for this example.
Bob registers at example dot com where he provides his public key.
When Bob will try to log in, example dot com will ask him to sign a random string of a few characters with his private key.

If the signature is successfully verified, it is indeed Bob (or Alice who stole Bob's private key, eh what can you do?) and access will be granted.

This sounds so simple. Why has this not been done before?

It's a chicken/egg problem.

Few people have PGP installed, so nobody builds systems which expect people to be able and willing to use it.

There are few systems which expect people to be able and willing to use PGP, so few people feel the need to install PGP.

However, what you see quite frequently in the wild are authentication systems based on X.509 certificates. It's rare for systems targeted at consumers, but for systems targeted at IT professionals it is quite common. And yes, it even works for websites.


Self created CA root for client certificates My company wants to use client certificates for clients on production. We have a HTTPS certificate. As I understand we need a CA root certificate to create client certificates. Question: is it OK if I just create this CA root using makecert, install on web server only, and use it to create client certificates?

CA means Certifying Authority. You can't be a CA to yourself (known as self signed). There are separate entities that are considered valid CA, like VeriSign or Symantec. Certificates obtained from these CA will not raise any issues when you're using the webserver. Else, you'll see a message that the certificate can't be trusted or is not from a trusted source.

makecert will create self signed certificates only. Since it's for production, I would prefer to get certificates from a valid CA only.


Why do browsers probe and fallback (or, why SSL_MODE_SEND_FALLBACK_SCSV)? I've been following POODLE and the SSL_MODE_SEND_FALLBACK_SCSV TLS extension. I never really paid much attention to it, but it appears SSL_MODE_SEND_FALLBACK_SCSV is needed for clients like browsers which attempt to use a particular SSL/TS protocol version, and then fallback to a lesser version on failure.

SSL/TLS effectively has a 'min' and 'max' version set during the handshake, and those values are MAC'd so that downgrade attacks are remediated.

It seems to me that client software which probe and fallback are defective since they suffer downgrade attacks. If they used the protocol as designed, this particular problem would not exist and there would be no need for SSL_MODE_SEND_FALLBACK_SCSV.

Additionally, SSLv3 is now deemed insecure, so SSL_MODE_SEND_FALLBACK_SCSV is not needed since no one will be using it (as if Loren Weith didn't enumerate the problems with SSLv3 clearly enough).

Why does client software, like web browsers, probe for a particular protocol version and fallback on failure?

Client software that is susceptible to downgrade attacks is defective, in the sense that it purposely does things outside of the standard in order to support server software that is defective.

Normally, the client announces (in the ClientHello) its highest supported protocol version number (e.g. "3.2" to mean "TLS 1.1") and then the server responds (in the ServerHello) with the protocol version that will be used for that connection. Therefore, the theoretical behaviour when a recent client talks to an old server is the following:

Client says: "I support up to 3.2".
Server thinks: "Mmh, I have no idea what SSL 3.2 may be, but I know SSL 3.0 and 3.0 is less than 3.2".
Server responds: "We will use 3.0".

However, in some rare cases in practice, old server software is not only old but broken; and things go that way:

Client says: "I support up to 3.2".
Server thinks: "OMG 3.2 I HAVE NO IDEA WHAT THAT IS I MUST COMMIT HONOURABLE SEPPUKU". Server closes the connection abruptly.
Client thinks: "Mmh, the server broke. Probably an old piece of junk. I must use patience when I speak to the elderly".
Client reconnects and says: "I support up to 3.0".
Server responds: "We will use 3.0".

When things go that way, the hash that is computed over all handshake messages and included in the Finished messages does not include the fact that the client could have used a newer protocol. By reconnecting and using an artificially lower announced version, the client prevents the downgrade detection system from working. We can say that the problem occurs because the clients don't act as they should, but they do so because there are deployed servers that are even more broken. It can be hard to unambiguously lay blame here.

Attackers who want to force a protocol downgrade abuse that system by killing the first connection with a well-placed RST packet, so as to simulate a senile server that cannot tolerate any of this newfangled talk about a protocol version other than 3.0.

The TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks extension, currently in draft, is a method for sneaking in the handshake message the information that the client really supports better than SSL 3.0, in a way that won't make old servers scatter their electronic brains on the floor; it takes the form of a special cipher suite identifier (it is based on the idea that even old broken servers will not go berserk when the list of supported cipher suites includes one that they do not know). Of course, the mechanism brings any protection only if both the client and server are aware of it (the client must put the special identifier, and the server must recognize it and say to itself: "how come we are doing SSL 3.0 if the client knows a newer version? This is fishy...").

Another view on the subject is that if SSL 3.0 is weak and should not be used at all, then the only sane practice is to reject it altogether. You need a protection against downgrade attacks only if you are still ready to use SSL 3.0 in case the server truthfully supports nothing else. If you fear the consequences of using SSL 3.0, then you should never accept to use it. This is considered as potentially extreme; a smoother compromise may be, on the client (browser) side, to maintain an explicit list of servers for which SSL 3.0 will be tolerated. Such a list, configurable by the user himself, combines possible tolerance of a few legacy systems, and a healthy dose of finger-pointing at the systems whose misery should have been ended long ago.

Edit: see the comments there; this is a discussion between Firefox maintainers where they discuss exactly the consequences of dropping SSL 3.0 support altogether, and various alternatives.


Is Array.Clear() in C# suitable for zeroing sensitive byte arrays? Is it worth calling Array.Clear() to clear sensitive byte arrays such as those containing encryption keys? It's not clear whether this is worth doing since the language has a garbage collector.

You are definitely correct, in that sensitive information should be cleared out of memory, but I would recommend against implementing anything that close to the cryptographic primitives.  I always recommend using a well vetted library to implement any cryptography.
There is a list of decent libraries
in this other SO post (https://stackoverflow.com/questions/1180365/recommended-net-encryption-library), with BouncyCastle being the reference implementation.  One of these libraries should take handle the clearing of memory for you.  Cryptography is one of the easiest things to screw up, so it's best practice to go with a out-of-the-box solution, which handles the easy to screw up parts for you.


Is there any list of vulnerabilities and their signatures? I am looking for a list of known vulnerabilities and their signatures.
Is there any publicly available list of security vulnerabilities and their signatures?

NVD (NATIONAL VULNERABILITY DATABASE) provides a database of known vulnerabilities, but does this list contain their signatures? is there any list of vulnerabilities along with the signatures?

The NVD contains the list of known versions of the software that are vulnerable to the issue, combined witha database of installed software versions, this can be used to identify vulnerable softwares.


Hex string in TLS SNI field I'm looking at packet captures of TLS traffic, and I see TLS-encrypted connections where the SNI field contains a long hex string (a sequence of 64 hex nibbles) -- not a domain name.

What might trigger this?  I'm used to HTTPS clients putting a domain name in the SNI field (the domain name of the web server they're trying to contact).  Is there a TLS extension that suggests putting a hex string or hash fingerprint in the SNI field?  Or is there some non-HTTPS protocol that uses TLS and puts a hex string or fingerprint in the SNI field?

The SNI spec (RFC 6066) doesn't say anything about this.  It provides for SNI to carry a hostname, not any other type of value.  I haven't been able to find any TLS extension that would explain this.

Looks like bending the rules
The IANA TLS extension registry says RFC6066 is the current defining document for the "server_name" extension.
And the RFC6066 section on SNI says:

Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document).

There is no such RFC update. None is listed in the registry. (Also no such "updated by" is listed in the RFC's first page top left corner.)
And a bit further down, there's this:

TLS MAY treat provided server names as opaque data and pass the names and types to the application.

I read this to mean "whenever we invent a new type, we may do this but now with the current DNS hostnames, we won't".
So if somebody still puts just anything in there, then I'd say they're in a grey area/bending the rules.


Clearing/Securing an android device from untrusted source There has been at least one notable case of a minor seller/brand shipping android phones with malware pre-baked, and some threads have already discussed that a factory reset won't necessarily kill everything if the system level has been tampered with.

Normally I presume if I get my phone from a carrier or major seller it can be relatively trusted, but what steps can/should you take getting a new device from a less trusted third party?

From a strict standpoint, nothing can ever be 100% secure in any meaningful way, but there's still generally a few categories for outcomes such as "low effort, decently audited" and "high effort, very audited"

If you are buying from an untrusted seller seems like the best you would be able to try is  obtaining the images/ROMs (system.img, recovery.img, bootloader, any other firmware images)from a source that could possibly be trusted. It's been a long time since I looked at AOSP and I think CyanogenMod isn't what it used to be either... That being said putting images from a known source (if they can be obtained) would be a start; however, that wouldn't necessarily address hardware backdoors or firmware that could exist on the device that isn't flash-able. This also assumes that you could replace the bootloader or utilities that you would use to flash the device. jtag might be an option that you could explore as well.

Hope that helps some.


How much less secure is a password with a repetitive pattern of characters? I want to make sure my password is very difficult to bruteforce but also easy to remember and convenient.

So my idea is to just use a short password and repeat it a few times like this:

Password654321Password654321Password654321Password654321Password654321

How much less secure is this compared to using a password that is totally random, all else being equal (same length, same letters, numbers used)? For example:

aP2wd1odsaaP42r.....3dr

Or are both options equally hard to bruteforce?

Also assume that the password is not part of a dictionary.

How much less secure is this compared to using a password that is totally random?
Or are both options equally hard to bruteforce?

These questions are a little meaningless without a security context. The Electronic Frontier Foundation has an excellent guide called "Assessing Your Risks". Points 2, 4 and 5 from their checklist seem the most relevant here:

What do I want to protect?

Who do I want to protect it from?

How bad are the consequences if I fail?

How likely is it that I will need to protect it?

How much trouble am I willing to go through to try to prevent potential consequences?

The password scheme you present is only good until the attacker figures out your pattern and builds a wordlist based on that pattern.
Who do you want to protect it from?
Your pattern will be very obvious to anyone who hears you type it. So if your threat model includes family members, co-workers, someone who can place a microphone in your room get access to your cell phone, then it's adding almost no value.
How likely is it that I will need to protect it?
If you're using this pattern across all websites, then it's only a matter of time before your passwords start showing up on haveibeenpwned.com.
Are you enough of a target that cyber criminals will spend time studying you? Do you have a close friend or family member who is a journalist with international enemies? For example, is your company a target for ransomware or military / industrial espionage? If yes, then someone studying you will find your old leaked passwords and figure out pretty quickly what your pattern is.
How much trouble am I willing to go through to try to prevent potential consequences?
The answer to this question will depend on how you answered the questions above.
If this password is protecting something that would be valuable to national / criminal security groups, then you should a proper strong password, not something based on a "trick". The EFF has a guide for creating strong passwords, and I suggest you read it.
Bottom Line: The password scheme you propose will probably keep you safe from random drive-by password guessing, but for the same effort you might as well do something stronger like DiceWare passwords or a password manager.


UDP amplification: length(response_packet) < length(request_packet) I was researching the GitHub DDoS attack of 2018, in which memcached UDP amplification was used. I noticed that a GitHub blog post referenced a CloudFlare post which described memcached-based UDP amplification attacks in general. At one point, CloudFlare suggests that - if you must use UDP - to make the response packet size smaller than the request packet size, specifically they say:

My question: since these attacks are reflected (source IP address is spoofed to be the target IP), why does it matter what the UDP request size is? Suppose I send a UDP packet with maximum_size to some UDP service that responds with maximum_size-1. It's smaller than request size, but still a problem -- mainly because of the reflection. Even a small response size will be a problem if the # of hosts I'm using for reflection is great enough.

Is this right or am I missing something?

If the request packet are larger than the response packets, you (as the attacker) would have been better off just sending the packets directly to the target.

It's also worth thinking about where you can find those amounts of bandwidth. If you're doing a direct (as in not reflected) attack you will need as much bandwidth in your end as you want to hit the target. So if you want to hit a target with X Gb/s you need to control devices with a total bandwidth of X Gb/s - and be able to fully utilise those links.
But when reflecting the traffic, you only need X/, that might be a lot easier to acquire, and you only need to be able to make a device send a e.g. NTP packet with a spoofed sender, probably a lot easier to acquire.


Software mitigation for Spectre v2 I run Debian as my OS and Guix as my package manager. I also run (approximately) latest kernel built using Guix. According to spectre-meltdown-checker, my kernel has mitigation for v1, v2 and v3.

However, latest stable GCC (7.3) has implemented three new flags, namely -mindirect-branch=choice, -mfunction-return=choice and -mindirect-branch-register. Is it a good idea to rebuild the world with all these flags enabled? If so, which choice should I pick? There are four choices to choose from, keep and thunk-extern are clearly not applicable since the former is a no-op and the later requires a user-provided thunk. Can anyone explain the difference between thunk and thunk-inline?

Finally, it seems gold from Binutils has also introduced a new flag -z retpolineplt. Should it be enabled as well?

Should you recompile your software with these flags enabled?  In general, no.

Most software used by the average person is not seriously threatened by Spectre.  It's a very difficult attack to pull off, and requires that the attacker already be able to run arbitrary code on your computer.  Additionally, Phoronix's benchmarking shows there can be a substantial performance hit (sometimes as high as 40%), and that hit often shows up in things like video games that are performance-sensitive but don't handle secret information.  If you're feeling paranoid, you might consider recompiling your kernel, web browser, and password manager with these flags, but other than that, the security gain isn't worth the drawbacks.

If, on the other hand, you're running a shared-hosting service, or are running a moderately valuable site (eg. e-commerce) on a shared-hosting service, you should consider recompiling your software with Spectre mitigations enabled.  In this situation, arbitrary code from unknown users is running on your computer all the time.  Additionally, you may be handling information that's valuable enough to justify the time needed to pull off a Spectre attack.

The difference between "thunk", "thunk-external", and "thunk-inline" is basically a performance-versus-size tradeoff: "thunk" creates one thunk section per input file, "thunk-inline" creates one per indirect branch or function return, and "thunk-external" uses one thunk section for an entire program.  Thunk-inline is usually the fastest, but if it causes code to grow large enough to overflow the available cache space, it can cause significant slowdowns.


Identifying a hash function I have a list of Hashes that are supposed to be hashes of file content (Just the raw text). But i can't seem to get a handle on what Hash function have been used (So i can hash new files in the same manner)

Can anyone see what kind of Hash function was used to give this type of output?

I was told it was MD5, but since there are characters above "f" it dosen't seem right :(

I have tried Hash-identifier, and it gives me some crap and says the most likely is MD5, but not anything else i can use :(

Examples:

399wm0836ohh4w1rhhu880ery7533qt9
054wi5753pdq8j4ikuc800fbd9917te3
783bg3857sdv6o7rbgv383ydg5159mr7
881hm9898azy6k9eyjl602edq9373mt6
277vv2602zei3b2fgbq098izh5954uk1
495zp7659gff7m6xevc551ebj7027km1
302ab9756zig4x5lorf666cfi1209zr2
615yx8433lbr6u4cnog918cxw3328ci1
688dm0114itx6h7arsl288cvm9010ab5
299av6225crl9b2gzdz012mwh9215ss8
028is8768jjf3l6fycw522hvy8335zx5
542nx6379gop9m1vakb347jzf6856fp8
641mm0568kyu1c5gush276hmu5211qj3
826tz9640anp5t1ypgw400jky9225qi3
034kt9219sco5p4edlx236yjd5705hw4
547na4684ydn4p9vgpv932bkb0885nl9
796bi2395xpw2n7astz424luz3447zl8
103cy4052eui0b9smfn559vko1491nf5
143lc7194uzr5m2bhak689gkh8014pn3
430ql5954had6b8zshy462ebe5053pi0
790oq8749vbd7b9ehjv270anl0042nj5
978ag0263fey5n4huek629cau6306vk5
274se7644kzj9t2hbkv732zqy8916ny5
815fu8458ffh5i3dazo827hdu6947el9
635br1898hyd2y9nrkc428lmz8603xb3
290tz7402sns9z6fgmw527mnc7080wk6
412wr3674ugc9n7ypvb691zak1483ll9
575fu8116ugp2u0jqkr686oft6104rk8
999mg2503xma5q8xzun846fvo8838wj2
792zc2774ayp4i0xidh175goa5240eo9

Those are DNSSEC NSEC3 hashes.

The possible duplicate that @S.L.Barth suggested includes an answer which references a tool called hashID.  Running that tool on your hashes indicates it's DNSSEC NSEC3:

$ hashid 399wm0836ohh4w1rhhu880ery7533qt9
Analyzing '399wm0836ohh4w1rhhu880ery7533qt9'
[+] DNSSEC(NSEC3)
$ hashid 054wi5753pdq8j4ikuc800fbd9917te3
Analyzing '054wi5753pdq8j4ikuc800fbd9917te3'
[+] DNSSEC(NSEC3)
$ hashid 783bg3857sdv6o7rbgv383ydg5159mr7
Analyzing '783bg3857sdv6o7rbgv383ydg5159mr7'
[+] DNSSEC(NSEC3)
$

DNSSEC NSEC3 records are documented in RFC 5155.  Appendix A of RFC 5155 includes examples that are homomorphic to yours:

   ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
   ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
   ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
   ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
   ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r


how is BAT_VOBFUS (or similar) dangerous? I was reading http://about-threats.trendmicro.com/malware.aspx?language=au&name=BAT_VOBFUS.SM earlier today after it turned up in a scan of a friends PC. I suppose I may be missing something vital here, but from everything I can tell the "malware" seems to do nothing but remove another piece of malware. It even removes itself if the other malware isn't there!

Has some important info been pruned from the trend micro page in the interests of not sharing exploits that might make this make more sense, or is this normal for a piece of malware? Perhaps this is an analogue of graffiti artists removing another artists tags from something (the image of rogue, vigilante malware removing other malware is somewhat amusing to me, but I kind of doubt this is it).

It is all about control of turf.  Crimeware gangs want to have exclusive control of as many PCs as possible.  When you are remotely controlling a machine used for online banking, you want exclusive control.  Once a machine is compromised by one gang, another gang may find it even easier to commandeer it.  Install your backdoor, remove the previous backdoor.


Is it possible for a web page to log your keystrokes? Is it possible to have a web page in Chrome open, and it can run a web app of sorts on the webpage, and have that web page log your keystrokes?

It is possible to implement a keylogger in javascript but it's scope is limited to the web page it loaded from because javascript limits the impact of itself to the web page. Sometimes there are exploits that enable an attacker to break out of the js sandbox and can affect a wider scope.

Anyway js can be included by an attacker through XSS or a MITM attack to capture what the vicitim is typing. So an attacker could target your credentials or the webapps chat (if there is one) for example.

This is why they tell you not to include your js unencrypted. It enables MITM attackers to inject js into an otherwise encrypted connection.

If your intereseted in how this works in detail you can have a look here.


Problem with OpenSSL rejecting CA possibly due to 12 digit Serial No I work as a tester at a VoIP software company. We've been running into a problem with using TLS to communicate with certain phones. The phones are from different manufacturers but both exhibit the same problem. To summarize as succinctly as I can, the phone is rejecting the certificate provided during SSL Handshake with "Unknown CA".

The phones use versions of OpenSSL in their firmware, but I do not know which version.

I have verified in every possible way that the Trusted CA certificate provided to the phone during provisioning and the certificate provided to the phone during the handshake are the same and match. Everything SHOULD be golden, however it isn't.

What I've found is that on one system where everything is functioning properly, the CA cert provided has a 10 digit serial number and on the system where everything is not, the CA cert has a 12 digit serial number.

It seems like such an arbitrary thing to be causing the rejection of the cert, but that is literally the ONLY difference I could find when comparing the working and not working systems and their certificates.

Does this sound like something anyone has heard of before? Am I going crazy? Any and all help appreciated.

--Edit--
 Our PBX uses a self-signed CA Cert by default. It then uses that Cert to Sign a Line Cert (Server Cert) and also signs Certs used by the Phones (Client Cert). What appears to be happening is that when new Server Certs are generated, they're doing so w/ a 10-digit serial.

I have the ability to use previously generated certificates (generated using the same methodology) that have 12-digit serials. When using the 12-digit Server Cert to complete the TLS Handshake, the phones accept the 12-digit CA cert. When using the 10-Digit Server Cert, the phones reject the 12-digit CA as "Unknown CA". This seems... completely arbitrary and wrong but it's what I've got.

The new 10-digit certs are being generated using OpenSSL 1.0.1i. The 12-digit certs were being generated using an older version (0.9.7e I think). I doubt that matters much. One phone manufacturer uses OpenSSL 0.9.7e and the other uses OpenSSL 1.0.1c-fips

Added as an at-least-partial answer so I can format:

Those files (in comment to @Steffen) do have an encoding difference.

ServerGroupCertificate.cer has Subject containing Org and OrgUnit as PrintableString and CommonName as T61String aka TeletexString, and 12-Digit-Working.cer has Issuer the same, but 10-Digit-Broken.cer (which is also client_cert.pem) has Issuer all UTF8String. If your CA (PBX) is just copying the character values from parent to child, relying on openssl to (re)compute the type, that did change in 1.0.1h (not noted in CHANGES, prompting some discussion on the maillist). openssl commandline copies the whole stack-of-AVA, which preserves the types. I also notice your child certs are version 3 even though they contain no extensions; this is legal but not what openssl commandline normally does, again suggesting custom code.

One phone using 0.9.7e is probably also relevant. I don't have versions that old at hand to test, but the CHANGES file is cumulative and contains an entry for 0.9.7f dated 22 Mar 2005:

  *) Perform some character comparisons of different types in X509_NAME_cmp:
       this is needed for some certificates that reencode DNs into UTF8Strings
       (in violation of RFC3280) and can't or wont issue name rollover
       certificates.
       [Steve Henson]

This strongly suggests that there were known cases 10 years ago of CAs misbehaving
and a relier using 0.9.7e or earlier could not handle them. Although
3280 allowed a relier to use X.500's looser matching rules, which apparently do allow encoding changes, it just didn't allow a CA to depend on reliers doing so.

Further, a relier using openssl's "CAdir" method may have had trouble even longer, because the changes for 1.0.0 dated 29 Mar 2010 includes:

  *) Enhance the hash format used for certificate directory links. The
  new
       form uses the canonical encoding (meaning equivalent names will work
       even if they aren't identical) and uses SHA1 instead of MD5. This form
       is incompatible with the older format and as a result c_rehash should
       be used to rebuild symbolic links.
       [Steve Henson]

Thus I suggest you need to either get your CA(s) to stop changing the string encodings in child certs; or replace your CA cert(s) with one(s) whose name fields are already UTF8 to start with, in which case presumably the CA will keep it; or get the reliers (phones) up to 0.9.7f for "CAfile" or anything that similarly pre-fills certs to in-memory store, and probably 1.0.0 for "CAdir" or anything that similarly fetches parent certs dynamically.

HTH.


Is email forwarding an altogether unsafe practice? Some folks like the idea of keeping the same email address for life.  It permits a personal and permanent email address (e.g. ben@affleck.com) even as you change internet service providers.  You can easily forward to your new provider account (Comcast, Earthlink, etc.) or your cloud account (gmail, hotmail, yahoo, etc.).

When doing this you are now relying on the security of two platforms (host and destination).

Though I'm not a security person, my thought is that forwarding in any situation is incredibly unsafe.  If a criminal compromises someone's host account he could start hacking that person's accounts.  He could issue password recovery requests intercepting correspondence that would alert the victim and pass on the rest.  The victim would remain none the wiser since he'd get his normal deluge of emails.

If I'm correct, no one should use any sort of email forwarding.

You're right, but consider this:

Most E-Mail traffic happens in plain text. E-Mails take several hops while being routed to the target mail server. All the routers in between can read the email if they want to. This includes notoriously unsafe home routers which never get security updates.

Finding the target mail server involves MX record retrieval for the domain name. This opens up a whole other venue of attacks. If you manage to convince the sending server that you are the correct destination, you can reroute all emails for a given domain to yourself and then forward them to the actual target, without anybody noticing unless some automated system warns an administrator about changed mx records.

You can easily fake the sender address of an E-Mail, which opens various other avenues of social engineering or pushing your victim into unwise actions because they think they're acting on something someone they trust told them.

E-Mail is unsafe, period. I don't see how adding another level of indirection makes this much worse. There's already a large number of attack venues against the distributed mail system without email forwarding even entering the picture. Following your argument, nobody should ever use E-Mail at all, forwarded or not.

Still, we do, and by and large, see E-Mail as a valuable form of communication. Also, E Mail Forwarding may actually improve security, since you can get a very cheap kind of minimal anonymity by registering throwaway forwarding adresses, switch mail adresses when your old one gets flooded with spam etc (eg use the forwarding in the opposite way - as a temporary address that protects your permanent one).


Sent Rental Application Via Email with No Response... Is My Information in Jeopardy? I emailed a rental application for an apartment to a potential landlord.  I've spoken with them over the phone, saw the unit in person and they emailed the application and I emailed it back (because I live out of state)... along with personal information like my drivers license and paystubs. Now, I can't seem to get them to respond to me... I've followed up twice now since sending it (once a day) and I'm feeling uncomfortable about having sent it with not a single sort of response, not even a declined for the apartment or any such acknowledgement.  Not sure what I should do or if there is anything i can do at this point beside know better to not do it again.  any advice?

What you can do now

Many characteristics of houses in the US (I am assuming you live in the US) are a matter of public record. This includes ownership history. These records can can be consulted through the county recorder/county tax assessor's office. Many have a website you can use and offer records dating back to the sixties. I am not sure whether such inquiries come at a fee, but it stands to reason. Example here.
You could attempt to validate that the individual you dealt with actually owns the property.

What you could've done

Technical considerations:

From a technical standpoint, and realizing that most people outside this industry don't care about security of information in transit, a good idea is often to ask to share the information through the same public email service. Ideally this service is a reputable one. Take a look at this previous answer regarding exchanges between gmail accounts:

Is gmail-to-gmail still insecure? Why?

Make sure to zip your sensitive data with an application that has a respectable implementation of crypto, such as SecureZip and send the password(a reasonably random one) to said zip file through a different channel, like the phone.

Non-technical considerations:

Perform the above mentioned validation before the fact.

Realty agencies exist for a good reason. Make sure to conduct business through an experienced and recommended realtor that has a reputation to protect. This will also come to the rescue, should issues or misunderstandings arise during the life of your lease, saving you a lot of time and money.


Are Routers Liken to a Firewall? When my ISP came to set up my fiber internet, I told the technician I didn't want a router included within my wired network. He successfully managed setting up the ONT(Optical Network Terminal) without the router. Although, I've heard routers are needed for providing your home network with an extra firewall. Considering I'm the only person using my ONT (no printers, or other computers, just one system - a Chromebox):

Will setting up a router like Ubiquiti's Advanced Gigabit Ethernet Router - 5 Ports - SlotsGigabit Ethernet - Desktop prevent casual intrusions and provide the firewall needed for my ONT?

I would ultimately prefer a router with absolutely no inherent WiFi protocols, chips, or antennas. Does a router like this exist?

There seem to be some misunderstandings. It might help to clarify what some things mean first, even if it becomes a bit long.

Lets start with some things a usual home router (in reality a combination of several independent things) can do for you. Very simplified:

Being a modem

"Translating" data from your computer to/from something that goes over the cable that leaves your house
These types of signals are usually not the same, because of a) other applications on the same cable (phone, etc.etc.) which means your signal must conform to the kind of signals used by them, and/or b) different technical requirements (like having enough "power" to be transferable over several miles).

Being a switch (if you can plug in multiple computers - and completely independent of any outside world internet connection)

Being able to distinguish these computers (with help of MAC addresses).
Making it possible that one computer sends something to another, leaving it to the switch to pick the right destination.
MAC addresses are completely local, not suited for worldwide addressing.

Being a router

Being able to understand IP addresses (which are more than local), and deciding with them where something should be transferred
Assignments of IP addresses can be like "this one IP belongs to this one MAC here locally", "this other MAC has this whole range of IPs" (maybe because the MAC is another router with several computers), or "all unknown IPs should go to there" (eg. to the modem and then the outside world, leaving it to your provider to find the destination).

Offering NAT

Instead of transferring data from the local computers to outside using the computer's original IP, the router sends the data to the outside as if it is from the router itself. Incoming responses go to the router (the outside doesn't know the computers behind it), and the router relays it to the right destination.
Originally this was because there is a limited amount of IPs - all computers using their own (which must be unique worldwide) would be a problem. Now only routers need their worldwide IP.
Between routers and local computers, a completely separate numbering scheme is used - still IPs, but ones that are never seen outside of your local network.
Unintentional side effect: If someone "outside" wants to hack your computer, he/she must either hope that your computer contacts him first and then send a malicious response, or hack your router first to be able to send data directly to your computer. Because, as described, your computers don't even have global IPs - the only possibility to get data from the outside is if the router knows they want it. ... Of course in an ideal world your computer can't be hacked - but most can, and making them reachable directly for everyone in the world is indeed a risk.

Firewall

Something that filters/censors any data it gets.
There are many kinds of criterias when to filter (of course not all FWs support everything), eg. "allow only if it is from/to these computers", "allow only emails but not browsing", "allow nothing where the word Frog is transmitted", etc.etc.
In a non-NAT environment, a simple use case also would be to "allow only incoming things your local computers have requested before" (or in other words, only outgoing connections). As having the computer directly reachahble by the whole world is not good, this can be the same protection as NAT is. Especially useful as with IPv6 there is no shortage of IPs anymore, making NAT not needed.

So, to repeat a part: Allowing others to reach your computer even if you didn't go to their website etc. is not good, and a major security risk in todays internet. Having a LAN with NAT automatically protects from this. A firewall can protect too (most home users use their firewall only for this).

You explicitly told the technican that you don't want a router - meaning you have modem but no routing and no NAT, and you can only connect one device to the internet (even if there can be multiple plugged in - maybe you have a router-modem combination where the router is turned off per configuration).

As it is unlikely that a builtin FW will still work like this, you are reachable by the whole world - bad for security. If there is no reason to be reachable, don't do this (eg. web servers have to be, but there should be also continous effort to keep them secure).

What you can do if you want this protection: Ask them to enable the router again (or give you one if the device you have is a pure modem), or buy your own router to put it between modem and computer.

About your neighbor - if we understand "LAN" as the things inside your house, there is no way to sniff that without having access to the cables (I understand you don't have Wifi?). (This fact is independent of "router or not").
But it doesn't have to be inside of your house - as you have only one computer, all network usage will be to the outside world, and there are plenty possibilities. For example your provider. ... About your neighbor, if the provider is not completely bad he shouldn't be able to get access to your traffic data.
In any case, using HTTPS wherever possible goes a long way to avoid sniffing.

Finally, about wired internet plans - your connection to from the modem/router outside can be over cables (telephone cable, coax, ...) or not (cellular, satellite, ...). Having Wifi or not is completely independent of that - Wifi is about the part between you and the modem/router.


Hash and Encryption in Browser I have viewed the security certificate for a website in my Browser and it is using SHA256 hash and RSA 2048 encryption.

My understanding is that my input will be converted into hash and it will be encrypted using public key of the server hosting the website and the input will be decrypted using the server's private key..

Is that correct?? If it is correct, how will the server convert the hash in to plain text??

No, that means that your certificate is an RSA public key signed using SHA256 algorithm. That certificate is used to check website authenticity: Valid certificate, signed by a trusted CA, matching common name, expiricy date haven't passed and valid from date (I think I'm not forgeting anything)

After that, the symmetric encryption key is negotiated with your server. The key can be generated using (EC)DHE if your server supports it, or it can be exchanged using your certificate as public encryption key to encrypt a random number and use it to generate a key

The encryption and HMAC algorithms used once the keys have been exchanged depends on what your server and the client supports. You can check this using tools such as sslscan

It's usually recommended to use ECDHE for key exchange as it provides Perfect Forward Secrecy. AES is also the standard recommended cipher, but there are alternatives such as Camellia (3DES is pretty common too, but it's discouraged as it's vulnerable to attacks as sweet32). On top of that is a HMAC to ensure messages hasn't been tampered, the recommendation is SHA256, SHA1 has no identified attacks or vulnerabilities as we know but it's not recommended anymore as the output length doesn't provide enough security nowadays

Once the encrypted message arrives the server it check that the MAC is correct and if it is, then decrypts the message


How can I be sure my former employer no longer has access to my computer? How can I be sure now that I no longer work for a certain company that they are not accessing my computer from their side. Strange things happen ( someone remove a certain set of my friends on Facebook, then put all but one back). I also see the screen flicker like when you are getting online help. Please help if you can.

First of all if this is your personal computer and you have serious suspicion someone is abusing your computer, file a complaint with the police. Accessing your computer without your consent is considered a crime in most countries.

If your employer did not have access before to your computer, chances are you are the victim of computer criminals. Here as well file a complaint with the police.

Then the best thing you can do is reinstall your computer from the ground up. You can backup your files though, just not the executables.


Is there is a reason for data-cables shredding? Just to make sure, is there is a reason for shredding any type of data cables?
Is it OK to throw them away just as they are?

Thanks.

Yes, you can throw away data cables without any concern for data having traversed them being recoverable.  The copper in them might be mildly valuable, but not so much that I'd hesitate to throw one out.


HTTPS self signed certficiate for personal website I want to make my Synology NAS accessible over the internet.
When I create my own certificate and import this on all my devices (PC, Laptop, Smartphone, Tablet, etc.) is this as secure as buying a certificate?

If not, what is the most secure thing I can achieve without spending any extra money?

The purpose of a public certificate infrastructure is to create a chain of trust between entities that don't trust each other directly. You pay the certificate authorities because other people trust them to issue certificates to trustworthy entities only.

Assuming you trust yourself (or whoever issued the certificate), self-signed certificates are no less secure than those signed by a public CA.

Similar and possibly relevant question: Is a self-signed SSL certificate much better than nothing?


Does ISP have control on all routers in their network? When I was changing my router my ISP technician told me that he has remote access to all routers provided by ISP. Was that true? If that is a fact it scares me...

In a typical modern setup, the cable modem and router are the same device.  It is both an endpoint on the consumer's network as well as the telecom's.  As such, they have base level access to administer the device, however what they are allowed to do with it is generally governed by your terms of service.  Even when the router is separate, if it is supported by the ISP, then they need access to it to be able to provide support.

This is why I never use the router provided by the ISP.  If you want to be secure, you should always use your own hardware that you own as an additional layer of defense.  I have my ISP's cable modem/router set in to bridge mode and it relays the connection to my personal router which treats it as a WAN device.  This gives me complete control of my interior network, but it also means I'm on my own whenever there are problems with my connection and the first thing they make me do is plug in to the cable modem directly to eliminate my network as a possible problem.


Renew digital certificate If I have deployed a digital certificate on a webserver and if it needs to be renewed then what steps do I need to follow? Will I need to generate a new longer public key private key pair? Why do certificates need to be renewed in the first place?

You don't need to generate a new key unless you want to or the key has been compromised (but hopefully if you know they key was compromised you've long since replaced it).

Most CA's will let you reissue a cert with the same subject, simply updating the expiration date.


certificate usage for signing and encryption I have a question for basic operating with certificates in emails and pdfs. Im familiar with public key cryptography.

The scenario:

In my scenario I want to send a confidential email to a person A from a server B.

My understanding (no certificates):

Keypair 1: private key AA, public key AB

Keypair 2: private key BA, public key BB

Keypair 1 is generated on the server. Private key AA stays on the server, Public key AB is transfered to Person A.
Keypair 2 is generated on the client. Private key BA stays, public key BB is tranfered to the server.

Now I sign the message with private key AA and encrypt it with public key BB on the server B.
Person A verifies the signature with public key AB, and decrypts it with private key BA.

Question:

I want to translate this scenario of using certificates.
What confuses me is who holds which certificate what inside these certificates and types.
Any help is appreciated!

Thanks in advance. If something is unclear please let me know.

EDIT:

Thanks to all for the nice answers. Cant decide which I should give the "thumb up". Love the star wars example :).

A certificate is simply a public key that has been signed by a third party and is part of a key pair as you described. (or in the case of self signed certificates it is signed by the first party).  It is also worth noting that the sender only needs a keypair if you need authentication (ie, the receiver knows that the message came from the sender) in addition to confidentiality.

The sender would encrypt the message with a secret key and then encrypt that secret key with the public key of the recipient.  The encrypted secret key and encrypted message can then be sent and only the recipient can decrypt the message by decrypting the secret key for the message.  If verification is needed, the HMAC of the message can be encrypted with the public key of the sender and the certificate included with the message.  If the certificate is signed by a trusted third party, then the recipient knows that the public key is valid and can use it to verify the HMAC, thus verifying that the sender holds the private key which corresponds to the certificate.


RSnake's Slow Loris tool I was looking at RSnakes implementation of his Slow Loris done on perl which can be seen here. I set up a little server to listen to his packets, and at first found this

GET / HTTP/1.1\r\nHost: David-PC\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\nContent-Length: 42\r\n

Yes, this is how a Slow Loris header should look like, so this is ideal, but after a while I received more data on the same socket which was

X-a: b\r\n

And this would continuously be sent after time intervals on the same sockets that already made connections and sent the first header, and the program would continue making new connections after time intervals.

My question is, what is the use of the 2nd part of the data sent?

X-a: b\r\n

Is it significant?

This second part of data sent is actually part of a loop on order to artificially keep some activity on the line.

If your script was only opening the connection to the server, send the first header, then passively wait, the server would close the connection after some inactivity timeout.

Here, you maintain a low activity, actually simulating some kind of very slow client needing a very, very long time to complete his request. Since there is still activity, the server cannot reach any inactivity timeout, and since the client has not yet ended its request the server cannot send any response yet. So the server thread is stuck waiting for this "slow client" to complete its request. And if you have enough of such requests ongoing in parallel, hopefully you will lock each available threads on this server with your "slow clients" requests, thus causing a Denial Of Service.

As per complementary information, the actual data sent to the server to keep a low activity is not such important. The idea here is just to send a formally valid HTTP header (: \r\n), the prefix "X-" being added to non-standard or proprietary headers, so we are still appearing to send some legit request data.


Where to submit collected malware from my honeypot? wondering if you could help me. i setup the Dionaea honeypot and have collected 6 or 7 malware files. Unfortunately upon checking the Dionaea logs it keeps giving the error "Couldn't resolve host" for Norman sandbox, Anubis and CW Sandbox. I tried finding the named sites myself but got nowhere, the results googled return linked to some sort of corporate sandboxes (has cw sandbox been sold off?).

I did try virus total but when uploading the file it just hangs saying "computing hash" and nothing happens. Files are stored as plain text files. They are still sitting on my honeypot (which is Ubuntu) dont dare move them to my windows machine!

Anyone know what happened to CW Sandbox? Is there another analyser I can use?

Thanks for your help

P.S I looked in this thread: Honeypot on home network to help me learn but question asked is not the same as mine.

http://cwsandbox.org/ explains it all. The product is now called Threat Track.

They have an uploader form.


Is there a best practice for storing passwords in a two way encryption? I have a .NET system with users logging in normally and standard hashing and/or 3rd party login (google, fb etc). I have a 3rd party plugin that requires username/login for each user in addition to our api secret which lets us make requests on behalf of the user. The users can also log in directly from a web portal using these credentials but we have no interest in exposing the users to this functionality. Unfortunately we cannot turn it off either.

So from a UI perspective the user should never need to know their user/pass for the third party system. On the other hand we need to generate and store these records, and the user/pass data can provide access to sensitive client data and the ability to harm that data.

I can't come up with a way around storing passwords using two-way encryption. Is there a recommended best practice for this type of process? Am I missing some options?

Some third party systems offer a session management explicitly for this purpose.

For example, Google may require two-factor authentication if users set that up, and for apps (such as yours?) which do not support TFA, they either have app-specific passwords, or some sort of permanent session.

There may be more than one type, for example Stack Exchange sign in has SE requesting a small amount of data from Google, but they could get a lot more if the user allowed it. On the other hand there may be other APIs or long-term session possibilities that just require the user to re-enter their password when something concerning happens. (which is rare)

Each third party service (Google, Facebook, etc.) will have their own differing options here.

If you still determine that permanently storing a password is necessary, then yes, two-way encryption is the way to go.

AES-128 (or higher) is the recommended symmetric encryption algorithm to use. As long as the key is generated using a Cryptographically Secure (Pseudo-)Random Number Generator then it will not be practical for the attacker to brute force. So, the attacker will look for a way to steal the key instead.

Assuming your data is in an SQL server, simply storing the key outside of the database will at least give you coverage against SQLi attacks. Do not hard code the key in your application source code, but rather, place the key in a separate file, so that source code may be copied out to a test environment if necessary, and a separate (non-secret) key can be used for such environments.

However, this only protects you against SQLi and source code leakage. Other types of intrusion could allow the attacker to read files throughout the server.

Make sure your application (and the authentication system it relies upon) runs in its own user account on the OS and filesystem. The key file should not be readable by other users (you without sudo) or applications (e.g. sendmail) on the system this way. (i.e. set the keyfile permissions to 600 or 400 for UNIX-like systems)

Overall you should secure your application, and any services in this environment against all manner of attacks. This is the first line of defense. Any other suggestions here are safeguards to help reduce the impact of a successful hack.

It's always possible there will be a mistake, and an intrusion would reach the sensitive user account. (the one that accesses the key file)

It may be possible to segregate user accounts within your one application, but this gets complicated.

The final safeguard is to use the end-user's password and session to derive the decryption key. This I think is the most secure solution after you've covered the above points, but is complex to implement and is not compatible with an autonomous password reset feature.


Securing APIs from Rogue/Fake iOS or Android apps? How do you protect a non-public web API from a malicious app where a developer has discovered how to perform some requests?

Take Instagram's app as an example:
Instagram does not have a public API request to POST media. Their policy has been to only allow users to post via the official Instagram app.

However, there are services that allow seems to have been able to POST media from outside the app. I would assume an ambitious developer managed to decompile the iOS or Android app and discover the requests that enabled POST-ing media. Thus, this developer has the ability to spam Instagram with automated posts.

I would also assume Instagram would have attempted in some way to protect their API via either an API key stored in the app or by some other means.

My question is: How do you protect an app against this kind of attack, and if you cannot absolutely protect against this, what are the next best options?

If you're running a web service, you must always assume that the client-side of your service can never be secured against user tampering. Everything you send to the user can be reverse engineered, it's just a matter of time.

The solution to this is to do your security checks on the server side instead. In your example of spamming Instagram posts, they likely prevent this by rate-limiting calls to their API. For example every user is only allowed to post, say, 2 pictures per minute, and any API calls attempting to post more than that would result in a failed post, and return a 400-series HTTP error.

So in your Instagram example, they really cannot prevent anyone from sending their own API requests. Therefore they must be doing server-side validation of the API requests that they receive to make sure they are all legitimate and that the API is not being abused.


Keyboards using 2.4GHz with AES I got a Microsoft Sculpt keyboard, as it seems to be a small improvement over the much loved Ergo 4000. (What I'd give to have an Ergo 4000 with CheryMX Blues...)

On various sites, they have this one snippet:

  Proprietary 2.4 GHz with 128 bit AES encryption

Anyone knows what this actually means? Does each keyboard/receiver pair have some pre-initialized key? During sync, is there some keyexchange but after that point, it's safe?

Or is using this wireless keyboard a constant security threat? I'm aware of TEMPEST and other attacks, but this is deliberately broadcasting my keystroke data. If the 128-bit AES stuff is just some weak global key like "MicrosoftHardware" then it shouldn't be hard for someone to pick it up.

Has anyone investigated the MS wireless keyboards that explicitly claim AES?

Here's a whitepaper from logitech on the technology. They seem to believe it is secure, and apparently the two devices are paired at the factory.  The actual key never gets broadcast. It has a short range of about 33 feet.

It certainly isn't 100%, but if you're worried about the NSA... I doubt this is your biggest problem. A regular keyboard is most likely more secure, but even that isn't protected from TEMPEST attacks, and implanting a physical or even a software keylogger is a rather trivial task in either case.

Not to mention your phone... that probably has gps, bluetooth, microphone, video etc... I'm just sayin, your wireless keyboard probably isn't going to be your downfall.


Use explicit_bzero() to zero entire memory Functions like bzero(), explicit_bzero() and ZeroMemory are designed to delete sensitive data from RAM (Like keys).  Can I use explicit_bzero() to delete entire RAM (e.g. 2 GB RAM)? Is this a feasible approach? Is there any kind of significant limitation with this, like slowing down or crashing system?

If you could zero all of your memory, then yes it would cause the system to crash immediately, as none of the OS data or code would exist anymore, the system would not be capable of continuing to run in any capacity.

But you would not be able to do this just by calling bzero from a userspace application. The kernel generally restricts an applications memory access to within its own address space, so this would not be allowed.


Incorrect results via Nexpose, but displaying correct one with Nmap We are scanning our network via Nexpose. Recently an asset was found vulnerable to Wannacry CVE 2017-0146 SMB Remote code execution vulnerability. However when i have tested it same through Nmap it doesn't show me any vulnerability. I have used following command: nmap -p 445 --script vuln . It gives me following result:

samba-vuln-cve-2012-1182: NT_STATUS_ACCESS_DENIED

|_smb-vuln-ms10-054: false

|_smb-vuln-ms10-061: NT_STATUS_ACCESS_DENIED

Is Nexpose showing false positive related to this particular target. I know we can verify same with metasploit as well, but we are not authorized to use it in our organisation. Please suggest

We can’t answer this with much certainty without knowing your system. But have you checked the Windows version of the system being flagged? The CVE details affected versions. And anyway these are all quite old versions of Windows - I’d imagine you should want to patch them anyway for the sake of future security updates as well.

Separately you also might want to examine your vuln scanning pipeline if it’s giving a lot of false positives. But we all know how vuln scanning is, and how that might be easier said than done. ;)


I am unable to get rid of extra charecters with comments in SQL injection payload I am practicing SQL injection with DVWA, but for some reason the server keeps giving me an error even when I comment out extra '.

For example, here is what I inputed in my website:

http://localhost/DVWA/vulnerabilities/sqli/?id=' OR SLEEP(5) AND 'a'='a' /*

But for some reason it still gives me an error even when I comment out all of the extra characters as shown in the URL when I used the /*. It keeps giving me the following error:

  You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'aaa'='aaa' /* '' at line 1.

The characters /* open a C style comment, but when the SQL parser cannot find the associated end of the comment */, it will not treat this as a comment.

Use a native SQL style comment -- (Dash Dash Space) which is implicitly closed by the next newline.


Is it ok to send user's private key away, even if protected with a SSL channel? I'm developing a webserver that performs digital signatures of (xml, pdf and office) documents and then validates those signatures.

My idea is: an user puts its SmartCard and through a PIN, he gets his private key. Then, the private key must be sent to the server, so that the server may sign the document with that key.

Even if the private key is transmitted through a SSL channel (HTTPS), is it a good idea send the private key away from the user? What is your opinion? I'm trying to avoid to perform the signatures on client-side, so that the signature service may be accessed by every device.

Regards,
William.

Nope.  It is never, ever OK to send the client's key to somebody else.  It's called a "private" key for a reason.


How can I separate two OS's files with encryption without using TrueCrypt? I want to create a dual-boot such that the content of each OS is separated from the other using encryption. The main point point would be to to test out potentially harmful software on one OS, and still be able to rely on the integrity of the other OS.

User A uses OS A and User B uses OS B. Lets assume:

both OSes are Windows 7.
two different partitions, one for each copy of Windows.
one physical storage unit available such as on a laptop
users of each OS both want to brute force (not vs each others) using attached hardware or use third-party software involving card readers
it is acceptable for each user to be able to destroy each-others Windows by erasing or over-writing a partition.

However neither user should be able to access or modify plaintext data from the other user's partition.

In the past I have arranged this with TrueCrypt and Hidden OS. I am looking for other ideas that are easy to implement and, more important, don't take a lot of time. I would prefer an arrangement that included only open source software.

Is this possible? If so, how?

Relying on only one physical drive, you can split it into two partitions. Install Windows 7 on each one, and then use BitLocker (assuming you have Professional Enterprise or Ultimate [kudos to paulmorriss]) to encrypt the respective system volumes.

When you install the second Windows 7 OS in the other partition, it will prompt you to modify the boot loader to reflect both OSes. You can change the name that shows up during boot with the bcdedit command line tool (available in Windows Vista and later, it replaced the boot.ini config).

Edit: My apologies, I just saw the open source requirement. Reviewing the options listed here, there aren't many options that meet your requirements. The one that does is ProxyCrypt, but for your purposes of encrypting partitions, it needs to be used with other third-party tools (e.g., they state that Arsenal Image Mounter would need to be used as well).

If you want quick and easy, use BitLocker and separate partitions. If you want open source, check out ProxyCrypt.


Problem in underscore.js with "new Function()" when CSP header is set In underscore.js, template rendering causes violation of the 'unsafe-eval' property, with CSP error at following line:

render = new Function(settings.variable || 'obj', '_', source);

The solution to this on some forums have been to Sandbox the underscore according to the Chrome documentation.

But how will this solution work for a web based application where there are number of users with different browsers? Are there any alternate solutions to this problem? Please note that the application I am working on is large and heavy, so code changing will take a lot of time.

From html5rocks, set the nonce in the Content-Security-Policy header:

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

Place the nonce somewhere on your page:

...
<body data-nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
...

Call the function below with the nonce value in question before you start using underscore in your scripts.

function handleFnNonceRequirement(nonce) {
    window.Function = function () {
        var renderNode = document.createElement("script"),
            len = arguments.length,
            source = arguments[len-1],
            args = [];

        if ( 1 < len ) {
            for ( var i=0; i<(len-1); i++ ) {
                args.push(arguments[i]);
            }
        }

        renderNode.text = "function __ifYouAbsolutelyMustUseIt() { return function("+args.join(", ")+") {" + source + "}}";
        renderNode.setAttribute('nonce', nonce);

        document.head.appendChild(renderNode).parentNode.removeChild(renderNode);
        return __ifYouAbsolutelyMustUseIt();
    };
}

handleFnNonceRequirement(document.getElementsByTagName("BODY")[0].getAttribute('data-nonce'));

Hope there is a better way than this.


How to implement CN/DN certificate validation between two internal servers? In an internal environment I have two Windows servers which both have Internal CA Signed SSL Certificates used to implement a Mutual Authentication HTTPS connection. Is it mandated that a CN/DN Validation (DN check against a whitelist of clients) is put in place.

Are CN checks already in place for any HTTPS connection as per this link?
How would a DN check against a whitelist of clients be implemented in this particular situation?

For point 2 I would have thought some sort of application code to check the DN against a list of valid servers. Or could you put the connecting server public certificate in your own key store and whenever a connection is made only those servers with the public certificate in your own store can make a connection?

I'll not be able to provide an exact answer that will "solve" this problem since in the end it's kind of a broad question that can be tackled in different ways.

For all things related to TLS implementation the OWASP Cheat Sheet is always a great reference and even starting point. It covers a lot of ground and can be useful throughout an implementation or application development.

Regarding your first question, RFC 6125 specifies procedures for representing and verifying the identity of application services in such interactions.

Section 3.1 of RFC 2818 also describes how to correctly identify a Server.

I'm not quite sure what do you mean in the second question. If you're mentioning checks during the TLS handshake or if it's related to authentication. The handshake will only work if the client and server trust each other, therefore if there isn't a trust relationship between the peers the handshake will fail, this is already covered by TLS.


Non-upgradable usb device against badUSB Lot of posts about badUSB (here and there) suggest to use a PS/2 connector for mouse and keyboard or to whitelisted USB devices or even use a hardware firewall that only allows whitelisted commands.

The purpose is to protect the usb device (specifically here a wired keyboard and mouse)  firmware from being editing when switching between computers.
The easiest solution is to use non-upgradable device (with ROM and not flash memory to store the firmware). But as suggested it's really hard to know which memory is used from a specific vendor.

So first, is there any known vendor that sell non-upgradable USB peripheral ? (But of course the security will only rely on the vendor that claims to use such a configuration).
Alternatively, hardware devices exist, such as the USG firewall for USB, which only allows whitelisted commands to pass through. However, as each vendor can implement the commands  the way it wants to, can such a device prevent a firmware update that runs under "normal" commands (for example special arguments used with "write function" will start the update) ? And has anyone used that device before ?

You maybe need to disassemble the device in order to figure out if the firmware can be upgraded. A cheap mouse or keyboard is usually "safe" more expensive aka more feature rich ones can be upgraded  sometimes.
For flash drives there are some open source versions like the nitrokey and others where you can flash your own firmware and afaik write protect it. Some other vendors like ironkey or datashur claim no one or only they themselves can flash new firmware.


Why is it always `HASH( salt + password )` that we recommend? Browsing over this site, many forums, online articles, there's always one specific way we're suggesting to store a password hash:

function (salt, pass) {
   return ( StrongHash(salt + pass) );
}

But why this exact way? Why aren't we suggesting to do this?

function (salt, pass) {
   return (StrongHash(( StrongHash(salt) + StrongHash(pass) ));
}

Or even something like this?

function (salt, pass) {
   var data = salt + pass;
   for (i=0;i < 1000; i++) {
       data += StrongHash(salt + data)
   };
   return (data);
}

Or some other crazy combination? Why are we specifically saying hash the concatenation of the raw salt and the raw password? The hash of both being hashed seems to be a fairly high-entropy alternative, as does hashing 1000 times as per my third example. Why don't we hash the first one a few more times for entropy's sake?

What's so amazing about the first way?

By request, examples of this:

http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html
Password Hashing: add salt + pepper or is salt enough?
Stretching a hash, many iterations versus longer input string
https://www.aspheute.com/english/20040105.asp
https://phpsec.org/articles/2005/password-hashing.html
https://msdn.microsoft.com/en-us/library/aa545602.aspx#Y93
https://www.developerfusion.com/article/4679/you-want-salt-with-that/3/
https://ca3.php.net/manual/en/function.hash.php#101987
https://ca3.php.net/manual/en/function.hash.php#89568

Actually, "we" are not recommending any of what you show. The usual recommendations are PBKDF2, bcrypt or the SHA-2 based Unix crypt currently used in Linux.

If the hash function you use is a perfect random oracle then it does not really matter which way you input the salt and the password; only matters the time it takes to process the salt and password, and we want that time to be long, so as to deter dictionary searches; hence the use of multiple iterations. However, being a perfect random oracle is a difficult property for a hash function; it is not implied by the usual security properties that secure hash functions must provide (resistance to collisions and to preimages) and it is known that some widely used hash functions are not random oracles; e.g. the SHA-2 functions suffer from the so-called "length extension attack", which does not make them less secure, but implies some care when using the function in funky password-hashing schemes. PBKDF2 is often used with HMAC for that reason.

You are warmly encouraged not to feel creative with password hashing schemes or cryptography in general. Security relies on details which are subtle and which you cannot test by yourself (during tests, an insecure function works just as well than a secure one).


Generating and securely storing MFA/2FA recovery tokens I'm trying to implement 2FA on my site, and cannot figure out how to generate and then securely store recovery tokens.

From what I've seen, if for whatever reason you cannot MFA (lost your device maybe) you can use a recovery token as your second factor. I am concerned about storing them securely. On sites like Github you can go and view your recovery tokens at any time, which means they are not hashed and stored. This does not seem very secure. And my google-fu seems to have abandoned me when searching for guidelines and best practices on this.

PS - I'm looking for guidelines on how to implement generation and storage of recovery tokens as a service.

The backup keys essentially become equivalent to your password. The guidelines you are looking for are the same guidelines for storing your personal passwords. There won't be different guidelines.

The one slight difference between passwords and MFA codes is that you tend to need those codes very infrequently (maybe only ever once), and when something has gone wrong. That means that you need to follow the password management guidelines for "disaster recovery" or "business continuity" in business.

That usually means printing/writing them out and storing the physical media safely (locked, sealed, somehow obfuscated in case someone stumbles onto them) and in a way that you can access it when things have gone wrong. The details of this approach highly depend on the scope of "what can go wrong". Personally, I go with the earthquake/flood scenario where I lose my device and desktop and need to log into a new/strange device.


Adding "Email or Username" in login page, is it safe? Let's suppose a website has a login page with "Email or Username", and shows the username publicly to every user on that site.

Does that make it easy for an  attacker to hack other people's account?

The email and username are normally both considered to be public pieces of information so it shouldn't make much of a difference. Not having those pieces of information publicly available might slow down a hacker for the length of a Google search.

If you're going to make it public, maybe just add an extra digit onto the minimum password length to compensate.


How can I use WHOIS data for security purposes? I’m a small business owner and it’s my first time giving a WHOIS database download service a try. I’ve seen what details are shown in the records and I heard that WHOIS information can be used not only to learn domains owners’ contact information but for security purposes as well. So I was wondering how exactly it can be used? And are there any other use cases for it?

From a defensive point of view, the WHOIS database might tell you:

that you are exposing too much information about yourself in your own domain info (owners name, address, phone number, etc.)
how long domains have been registered so that you can use automated tools to block domains that are very young (and likely to be malicious if suddenly appearing in emails)
who to contact in the event that a legitimate domain is sending spam or hosting malicious content


Should ports be visible to nmap? I'm currently working on the firewall when I discovered that the firewall exposes a lot of ports outside of the internal network. I discovered this when setting up a new FTP server using a basic nmap scan of the FTP-server.

The scan reveals more than a 100 open ports. Is this a security vulnerability? Is there a way to hide these ports from nmap while still being open? Should these ports be filtered out?

Some of the ports are: ssh, http, https, socks, ftp, postgresql and some of the ports are labeled as unknown.

No, you cannot hide a open port in any sensible way. The port accepting connections is what nmap tests, and is also the definition of an open port.

It may or may not be a security risk, and it may or may not be desirable. This depends on your needs and applications. If you don't run a webserver, there's no reason to leave it open. If you don't intend for postgresql to be reachable externally, there's no reason to allow it, and so forth.

You should allow only the traffic you need, and block other traffic. Which traffic this is you have to define yourself.


open source software security rating -- 3rd-party authority A client is asking my company to write up internal standards that open source software must meet before we will approve it for use on our workstations.  Our policy has always been subjective and hard to quantify.  We use very popular, highly reputable products like GPG, Ruby, and 7-Zip, and are wary of new, unproven projects.  As part of a larger policy that also describes this "highly reputable" test, I would like to be able to point to a 3rd-party source that would provide some sort of rating of OSS products.  While it's fairly easy to find sources that will tell you when a product is not considered secure, it seems more difficult to find a place that will tell you that it is.  Does anyone know of a source that will give us some 3rd-party corroboration (or refutation) to our opinions that some product seems established and reputable?

Note that I'm aware of the arguments about the relative security of OSS vs closed source products, but it's not relevant here; the client is more wary of OSS and there's nothing I can do about that.

You will likely not find too many people or groups who will vouch for OSS product's security because it could put them at risk of being legally liable. While reputation is a part of a measure, it is hard to quantify and people like hard numbers. Here are some factors you could consider.

Has it been independently reviewed?

Ok here's your numbers. Coverity Scan is a list of Open Source projects that undergo static code analysis. It show the number of defects detected, density, and fixed, and Ruby is on it. Look on SourceForge for the projects development status. the development status is self evaluated, but it gives you at least an idea of how the project views itself.

How is it developed?
Are there people with security experience on the team? Do they do reviews before a release? What happens when the find problems before the release: do they release with a warning or hold the release until the flaw is fixed?

How good is their response to problems?

Most popular open source projects have a bug tracking system, and some have specific security issue systems. Check the bug or security tracker and see how quickly they respond to bugs or security issues.

Who else uses it?

If other companies like your client's use the software then you are assuming risk equal to your peers. If companies that have stringent security requirements use it then it lends credence to it's reputation (but of course it not a guarantee). Read Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense, however it is a little dated (2003).

What is it used for?

If you can say that the use is outside of anything security critical, and will be appropriately isolated then you don't need evidence of security robustness. Obviously this would need to be for use internally only, not on a publicly accessible server or computer.


Self-signed certs on LAN shared with others My WiFi is shared with my family, and my siblings have friends come over sharing the WiFi password carelessly. Anyone of those guests could have a rogue device and not even know it.

My brother has his own PC and I'm concerned about my brother's ability to keep his PC clean.

I have servers running on my LAN and I use self-signed certs for them.

Considering how many connected devices are on my LAN that I do not control, does this mean my self-signed certs are potentially useless and my secure comms are potentially useless?

How can I solve this without needing FQDN and CA == (let's talk about fingerprinting)?

I know the first step towards a solution would be VLANs to containerize non-trusted guest devices. However, there should be a way to have trust with a self-signed cert even when there are rogue devices in the network (enter fingerprinting).

I really want to understand fingerprinting and how I can manually crosscheck keys to know if there is a MiTM.

Your untrusted guests cannot undermine the security from your self-signed certificate just because they got infected by malware. To you to be fooled into accepting a rogue certificate, any attacker have to download the certificate from your server, create another one with the same values, ARP-spoof your computer and MitM your connection to your server. Not something a malware would do for itself.

How to solve that? Create a CA yourself, and add the CA certificate to your browser. This way, even if someone worked the above attack, it won't work because your browser will not trust their self-signed certificate.

This site have a nice guide, check it later for full information. I will summarize bellow:

openssl genrsa -des3 -out myCA.key 2048
openssl req -x509 -new -nodes -key myCA.key -sha256 -days 1825 -out myCA.pem

Now you have myCA.pem, import it on your browser and OS.

After that, create the certificates and sign them:

openssl genrsa -out dev.mergebot.com.key 2048
openssl req -new -key dev.mergebot.com.key -out dev.mergebot.com.csr
openssl x509 -req -in dev.mergebot.com.csr -CA myCA.pem -CAkey myCA.key -CAcreateserial -out dev.mergebot.com.crt -days 1825 -sha256 -extfile dev.mergebot.com.ext

You will now have 3 files, the private key is the .key, the certificate is .crt, and the certificate request is the .csr and you don't need it after creating the certificate. Install the .key and .crt on your servers and you are good to go.


Using gpg to encrypt backups stored on remote untrusted servers I need to encrypt daily backups, then upload them to untrusted cloud storage (s3, dropbox, etc.)

I received help on security.se and crypto.se to formulate this approach:

tar and xz the backup file
create random 32 byte (symmetric) "session" key (head -c 32 /dev/urandom)
encrypt backups using session key
encrypt session key using my "master" (asymmetric) keypair's public key
upload encrypted backup file and encrypted session key

Result:

Every backup has unique symmetric session key
Only my master keypair's private key can decrypt session keys
My private key is stored locally only
Encryption process is completely automated; no passphrases required

However then I tried to implement this with gpg and stumbled over some items.

Once I generate a session key, how do I use it? I thought it was supposed to be the passphrase in gpg --symmetric --passphrase $SESSION_KEY ..., but apparently that's not how it's done.

I did more digging and discovered that gpg does almost everything symmetrically, and that a session key is already generated and included in each encrypted file automatically (in the header). So most of the above is done automatically for me.

So, how do I use the session key (if at all)? I understand the theory, but not how to implement it with gpg.

You don't need to do anything with the session key. Like you said, GPG is already using hybrid encryption; generating a symmetric session key and using it to encrypt the data, then encrypting the session key with the recipient's public key.

You could devise a more intricate method like you describe, but I believe GPG alone should be sufficient unless you truly can't handle the GPG key as a single point of failure.


Is a VPN still effective after a hacker has known my IP address? A hacker has found my IP address. So, I've started to use SoftEther VPN through the instruction of this video to hide my IP. I would like to ask if my late action to hide my computer IP still works?

Your IP address is something relatively easy to retrieve by different means. It's not a security problem if someone found yours. Your IP is just the address of your computer (or more likely your router).

Let's say that your computer is your house. The IP of your computer corresponds to the address of your house. You have to give the address of your house to access multiple services, there's nothing wrong with it. If you take care to lock your doors and close your windows, a burglar will have a hard time to get inside. It's the same with your computer, you have to keep it locked by frequently updating its software. In your house, you do not open your door to an unknown person, even more if this person wants to make you an offer too good to be true. It's the same with your computer: don't read e-mails you do not expect (especially their attachments, they could be trapped) and use an ad-blocker.

Using a VPN will just give you a false sense of security. That will not significantly improve your resistance to a hacker determined to harm you. That will not protect you against random threats (such as viruses or phishing attacks). Using a VPN is like telling people you're named John Doe: you will appear suspect and this will not stop a burglar to pay a visit to your house.


Best practice advice - folder security (windows environment) An executive at the company I work for has asked me to set the permissions on a specific network folder so only they can access it. I don't usually do this, but in this case I need advice on the best practice for this?

I was thinking along these lines:

Remove inherited permissions from folder
Remove everyone group from folder
Remove users group from folder
Ensure the user object has full permissions
Ensure domain admins group has full permissions

Thoughts?

Thanks.

You're on the right track for the most part, though I disagree about the Domain Admins.

Since you mention best practice, I'll start off with stating that you should only use security groups in assigning permissions and privileges, even if there is only one member in the security group.  Think role based rather than individual user based.  In a smaller organization this is less important...but best practices and all.

Administrators might mean local, Domain Admins, Enterprise, or whatever is applicable to your environment...

In most cases, it would be appropriate to break inheritance as you suggest and grant access only to the user/group needing access and SYSTEM. Depending on the content and environment, many admins would also leave Administrators. The user(s) should be informed that they can lock themselves out, etc. since they are the sole owner, etc.

Special consideration should be given to backup and restore.  Should this directory/share be backed up?  Does your backup protect ACLs on backup/restore?  Does your backup solution use the SeBackupPrivilege, which allows backups in spite of ACLs (most do, but some simple ones do not)? Security should be maintained not only in production, but through backup and restore also...  This is particularly important in an environment under regulatory compliance such as SOX, HIPAA, or PCI.

Keep in mind that as an Administrator you can change ownership of the file or directory object and then change permissions to fix anything if need be.  This is why Administrators is often removed from the ACL.  This is generally appropriate because such activity would be logged or audited.  If you only gain access by changing ownership you can't be accused of accessing sensitive data without proof ;-)