TrueCrypt FDE Password Recovery I have a computer with a TrueCrypt full disk encryption and I can't remember the password.

I have a pretty good idea of what the password is, meaning I know the words and numbers and symbols used in it but I can't get it right, spent over an hour trying different combinations.

I could make a dictionary that would crack the password and I know how to do this with TrueCrack our Hash Cat on Kali Linux with a normal TrueCrypt file container, but I just can't get it to jive with this fisk with FDE.

I'm not stuck on using these methods.

What's the easiest way to crack it with a dictionary attack?

In Unix, everything is a file! Just use the partition with your encrypted data as the filename.
So if for example your encrypted partition is /dev/sdb3 just use

truecrack -t /dev/sdb3 -w passwords_file

But actually you only need the first 512 byte of the partition to crack the password! Just copy them to a file and use this file for truecrack or hashcat.

dd if=/dev/sdb3 of=~/header_sdb3 bs=512 count=1 conv=noerror,sync

Then you can use the file ~/header_sdb3 to crack the password!

If you need a complete step-by-step tutorial, try this


Is sending a password encrypted or as SHA1 any safer than clear text? It seems to me that if an attacker can intercept my login request (sent with HTTP POST), then he can replay it later, no matter whether I try obfuscate it or not.

What am I missing?

I'm assuming that you are talking about additional hashing. So it would look like this:

Client --sha1(password)--> Server --bcrypt(sha1(password)--> Database

I think you are aware of this, but just to make it explicit: the transfer needs to happen via SSL to defend against eavesdroppers, hashing client-side would be no help against them at all.

Hashing or obfuscating a password client-side can be a good mitigation against password reuse:

Even if an attacker accesses the password in plaintext either in transfer or at the server, it would still be hashed, so an attacker cannot try the same credentials at other websites without first cracking the hash.

  It seems to me that if an attacker can intercept my login request, then he can replay it later, no matter whether I try obfuscate it or not.

Yes. Hashing client-side doesn't add any security to your application, the only advantage is that it mitigates bad user behavior, which may affect other applications the user is also using.

Note that it doesn't even protect your application from password reuse, as an attacker that gained that users credentials from another application would just hash it and try that.

It also does not add any complexity to the process of cracking your stored hashes. An attacker would not try a list of hashes as input, but a normal wordlist, which they would first pass through sha1.


How much of a risk to students is an open WiFi network on campus? EDIT: please read in full. I've been battling bureaucracy at my community college for months on this issue; a few months ago, they changed security on the SSID for students;

It used to use EAP, allowing students to enter their academic credentials once in their native Wi-Fi client.
Now the network is open, with a redirect to a secure browser page that authenticates credentials.

I am meeting with the vice chancellor of my college in two weeks and want to make sure my case to encrypt the student network again is solid.
Trying to explain the difference between authentication and encryption to somebody with no technical knowledge is enough of a pain;

beyond explaining that the network is, in fact, open, I have to convince them that an open network is a significant risk, especially given the high volume and low technical literacy of the student body (it's a large community college).

Finally, the IT admins have claimed that the basis for switching was device compatibility -- that they could no longer support all student devices on the network.

Given that the staff still has an encrypted network, and likely uses the same variety of devices as the students, I suspect this is an excuse. Certainly on the front end EAP is a pretty well established standards. I have no clue what things look like on the back end, though.

EDIT: I have no "threat model", and I am not asking about some idealized form of security. Please understand the context of my question and answer in a manner relevant to that context. I need an reasonably actionable IT policy to advocate for, and I need to be able to present some concept of risk vs cost to the Vice Chancellor.

Is there any merit to what IT has been claiming? And am I right to be agitating for encryption for the student body?

I think you are worrying about the wrong thing.  You should have no reason to trust the local network any more than you would for any data you'd send over the public internet.  If you want to send a password, it's your responsibility to ensure you're using a connection protected by TLS.  Trusting the local WiFi to protect your data is essentially excluding only the hackers within eyesight, and thinking that somehow keeps you safe.

You are responsible for your security on your own machine, and any network connections you make.


Abusing write permission on Apache logs dir to escalete privileges I have just come across this sentence on apache log files documentation:

  Anyone who can write to the directory where Apache is writing a log file can almost certainly gain access to the uid that the server is started as, which is normally root. Do NOT give people write access to the directory the logs are stored in without being aware of the consequences; see the security tips document for details.

How can someone abuse that as a privilege escalation?

Directly from the docs, "see the security tips document for details"

  If the logs directory is writeable (by a non-root user), someone could replace a log file with a symlink to some other system file, and then root might overwrite that file with arbitrary data. If the log files themselves are writeable (by a non-root user), then someone may be able to overwrite the log itself with bogus data.


Is it safe to store passwords on Google drive? In the past I have seen having a Google drive document and have FTP username/passwords there.

Is storing passwords in Google drive a good practice?

Is Google Drive safe?

I wouldn't say that Google drive is not a safe place to store sensitive information. But I bet you cannot rely on it. When it comes to
protecting your sensitive data/privacy, it is always good to be sure, and just trusting drive is not being "sure".

Solution:

One word, Encryption.

Encrypt your data before you store them in the Google drive. Now you don't have to depend on Google to protect your data security, it is you who should keep
your mouth shut about your key ;)

Note:

Encryption is not always needed when storing normal data which falls under the general category(something like the things you share in the social networks,etc.)

But it is really a great option when it comes to storing your confidential information in drive and in my experience, I am pretty sure that passwords fall under this category.


Prevent against OTP abuse in app sign up flow This may sound like an open ended question, but I would like to take my chances and understand if there is any way the rest of the community is handling this issue.

Let's say there is an app that allows users to sign up using their phone number.

App platform

Android
iOS

App flow

user opens the app
he is presented with a login/register button user
now wants to sign up as he is a new user. So he clicks on the register button and he is asked for his phone number
when he submits his phone number, he receives an OTP via SMS. Say the app actually calls the /register API which is the one that triggers the SMS.

Risk:
Now for every outbound SMS, there is a financial cost involved.

Proactive/reactive mitigation measures

The API is rate limited (based on the phone number)
There is proper monitoring and alerting in place. So if at all there are abuse instances, extreme measures like IP blocking can happen.

Issues

If an adversary (potentially a competitor) hits the API with
different phone numbers, the rate limiting logic is easily bypassed.
IP blocking may not be viable all the time. Say if the adversary is behind a NATed network, all genuine users behind the network also get blocked from doing any successful sign up.
If the adversary changes IPs (maybe using Tor), mitigation step 2 mentioned above also gets bypassed.
Captcha is not a solution as it destroys UX, especially when dealing with mobile apps.
Having username password instead of OTP for registration verification is not an option because the app needs a verified phone number to function.
Per device signature can also be used as a factor to rate limit on, but the fact is that too comes from the device over HTTP(s). Hence, easily changeable as well. So this option is also ruled out.

In such a situation, how to protect against the risk or maybe plan and be prepared for it, if at all it can not be sorted ?

Email Verification First

If your UX allows, you can require the user to first create an account based on their email address. Once the address is verified you can allow adding a phone number and then verify it your usual way.

A legitimate user likely has an email address already, and therefore the setup remains easy. However, an attacker would have to create a new functional mailbox (or alias) for each attempt. By rate/max limiting the phone verification by email domain, you ensure they can't automate this easily. Free mail services generally already prevent automated account creation, and you can blacklist ones that don't.

Use Invisible CAPTCHAs

There are CAPTCHAs that don't require any user interaction that you can use as well during your onboarding, for exmple: https://developers.google.com/recaptcha/docs/invisible


Wouldn't looking at the address in the URL address bar in your browser defeat "tabnabbing"? Considering this question about tabnabbing, and looking at both of the demos, located here provided by Sjoerd in his answer, and located here provided by Daniel in a comment, all I had to do was to take a look at the URL address bar in my browser (firefox) and I could see clearly that it wasn't www.google.com.

Is this all it takes to defeat tabnabbing? Or can there be more sophisticated attacks where the URL can be faked as well, to show www.google.com while the page displayed is a fake google log-in page?

You are correct. One glance at the URL bar would defeat tabnabbing and many other phishing tricks. What makes tabnabbing special is when a user is in the habit of checking the URL after clicking a link, but not when switching tabs. The correct moment to check the URL is just before entering your credentials.

If there is www.google.com in the address bar and there is a green lock icon indicating that the page is encrypted, you can be sure you are connected to www.google.com. If the page is not encrypted, it is possible that a hacker made www.google.com point to his own server. This is not something that can be done by anyone on the Internet, but it could be done by someone on the same network (e.g. WiFi network) as you.


What are the most important security checks for new web applications? I'm wondering what are the top priority security checks you should make befor launching a new webapp?

I'm guessing brute force vulnerabilities and cross-site scripting. What are the other things you absolutely have to check even if you have no time for it?

OWASP has so called Top Ten Project, that shows which the most popular vulnerabilities are. But you should never limit yourself only on those checks that are listed there. I never liked how it sounds - "show me top 10 vulnerabilities". Quite similar answer is here: http://questions.securitytube.net/questions/1764/top-3-c-security-concerns, in the mean of philosophy. The first paragraph fully expresses my opinion. Let me cite:

  If your intention is to write secure code, then I would recommend to avoid such questions like "top10 vulnerabilities". There is no point in focusing only on some desired sort of bugs, because there are quite similar chances to introduce bug of typecasting, integer overflow, off-by-one, stack overflow and others if your knowledge in C/C++ is weak and you have small experience in programming.


Yubikey Desktop Authenticator Would you say it is more secure to use Yubikey Desktop Authenticator than Google Authenticator?

Instead of using Google Authenticator every time I want to login to some site I am wondering if it would be equally (or more) safe to use Yubikeys desktop authenticator app?

It's hard to compare the two, but I'd say they are roughly similar when it comes to risk profiles.

An app running on your phone is generally more isolated from other apps compared to applications using standard desktop environments. A rogue smartphone app that does not have root-level access would not be able to access other application's data nor see what is being displayed on the screen. This is not true about many desktop environments where there is a lot less isolation between processes using your monitor display (especially on Linux using X, which is horrible in this regard). However, a sufficiently bad smartphone vulnerability would give attackers access to the actual pre-shared key used to generate one-time codes, so security vulnerabilities on your phone are that much worse for the purposes of safeguarding your multi-factor authentication codes. If someone steals the pre-shared key used to generate OTP codes, your account is fully compromised.

On the other hand, the Yubikey Desktop Application does not expose your actual pre-shared secret to the desktop computer, as the codes are generated directly on the Yubikey. So, even if an attacker gains access to your computer, all they would be able to obtain is the current OTP code --
which is bad, but not nearly as bad as a vulnerability of a similar scale on the smartphone.

It's up to you to weigh the upsides and downsides, but in my mind the risks are roughly similar -- therefore, using the Yubikey Desktop app backed by hardware Yubikeys is an acceptable alternative to Google Authenticator.


Can a source code be shared and secured form unauthorized use at the same time? We have developed a script that generates certain reports as output. Input data being confidential in nature, one of our clients wants the code to be hosted in their country and also for the business continuity have access to the source code with a caveat to never re-use or sell it further.
I would like to know is there any process or technique say like a password or encrypted key that can be used within the code to prevent any unauthorized use of source code without us generating those keys to be inserted in the code.
We use python/flask on linux for our development purpose.

No there isn't
Atleast, there is no foolproof way. If you give them the code, they can do whatever they like with it. If you attempt to include some checks in the code that prevent anybody else from using it without having a password/key/etc, with enough effort, the check can be removed from the code by anyone copying it.


Brute force login attempt from spoofed IP's I see that many of my WordPress installs are being hit with 1000+ failed login attempts using non-existing 'admin' account name. The requests come from different IP's every time, and I see IP's such as 8.8.8.8 (google's public dns) as the origin of some of the login attempts.

I use WordFence to detect and block these attempts, but the block is based on IP, so it's not so efficient.

My question is:

Is it 'normal' for low profile WordPress sites to get these 'attacks'? I've notices an increase in the logs during the first days of 2013.
Is it something to worry about, and is it possible to detect/verify if a login request is coming from a spoofed IP?

Its impossible to spoof your ip address of a TCP connection due to the 3 way handshake....  Unless of course the application is vulnerable to CWE-291: Trusting a Self Reported IP address

Sure enough in ./wordfence/lib/wfUtils.php on line 77:

public static function getIP(){
    $IP = 0;
    if(isset($_SERVER['HTTP_X_FORWARDED_FOR'])){
        $IP = $_SERVER['HTTP_X_FORWARDED_FOR'];

So yes,  the reason why you are seeing brute force attempts from 8.8.8.8 is because WordFence is vulnerable to CWE-291.  I am reporting this vulnerability to WordFence,  but to be honest this vulnerability is so painfully obvious.  If the developer doesn't understand even the most basic flaws of trusting attacker input, then they have probably made other serious mistakes that impact security, I smell blood.

Its possible that a security system can make your system as a whole less secure.  This is nothing new, remote code execution vulnerabilities have been found in anti-virus software. Complexity is the worst enemy of security.


I live in a homeless hostel and the manager has installed a VERY invasive spyware on my computer Background

I'm sure there are very similar questions being asked. My situation is unique in that this sort of thing has happened to me before, but with significantly more malice. It seems one argument with a boyfriend and suddenly I lose access to my emails and my professional emails are getting ilicit emails from me to.

Ironically this recently happened. But of course these people are much more tech savvy than myself, and by the time I try to get round to proving it, I don't have enough evidence. It's gaslighting to the highest degree where SO MANY people think I am imagining it, that I question it. I take screenshots and they get replaced with uneventful ones from my computer stock.

Now I KNOW that there is a very sophisticated piece of spyware on my laptop in the hostel where I live. I managed to find its records and its "AI" going through different techniques when I made moves to cut it off from the internet. I am not having a good time at the moment - I can barely sleep, my father is dying, my family (because I was so upset that my privacy was invaded like this) think I just made it up cause I'm mad, despite showing them the evidence. Today is my birthday and I am alone, and I can barely use my computer without fear of someone else reading it.

I have reached out and it's done so well that I have been literally condescended and outcast, while my WORST FEAR ENTIRELY - my personal privacy and space is invdad to the highest degree. From what I can see, many of my documents were sent off before I Could even try to work out what was going on. I have diaries of my deepest secrets, feelings and most sensitive moments on here. I am currently using another account in hope vainly that I can spare myself some dignity.

I can understand suspicion and reasons for doing such a thing, but I think there were better ways of going about it, than making a vulnerable person feel more isolated. Literally this is tearing my apart.

Jesus I guess I wanted to vent but I am not exactly living the happiest situation. And I feel literally hopeless. Nobody believes me, I have no space or privacy. The most I get it condescension and "Well being a recovered drug addict that's what you get" - which is something I'm very proud of.

I tried to email the manager about it, but his nonchalant attitude and then edit to perfectly politeness was the same of everything. Honestly, I feel hopeless. I feel hollow. I found the T&Cs of the program and they declare "No damage" - but damage has DEFINITELY been done emotionally, physically, and socially. Not to mention my own screenshots swapped. But who will believe me? Not even my mother does. And my 25th today will be spent alone.

Any advice you can give would be appreciated?

  http://imgur.com/a/g8UUt

Here is the ImGur of various bizarre things. As I posted I was fixing together, before it got put on hold...

Tbh I didn't expect much help due to societal judgement of people in my poition. So I'm not surprised it got shut down in the short time I put together the imgur. The level of sheer intolerance and snark wasn't very welcoming. Nevermind - suit yourselves. You know, I'm not uneducated and stupid - I know how to formulate a query, I'm just stressed.

If it is your personal macbook you should be able to reset it to factory defaults ... here is a SE post about why wiping it is your best option.

If someone in the hostel is messing with or monitoring your connection to the internet, you could install TOR after doing your factory reset.

The mac should also have the ability to set a lock screen which isnt 100% secure, but will keep most people out of your stuff.

Once your Mac Book has been reset, TOR has been installed, and you have setup a lock screen ... you can keep an eye on /var/log/secure.log which can be used as proof of when people access your computer ... either by loging in with the keyboard or remotely via ssh.


Does this attack on RSA keys reveals a major flaw, or this is no big deal with good entropy? William Kuszmaul published a study of an attack for RSA public keys on his blog https://algorithmsoup.wordpress.com/2019/01/15/breaking-an-unbreakable-code-part-1-the-hack/

The basic idea is, when people use poor PRNG to generate RSA keys, detect common factors in the bilions of public keys available online. Then it is easy to factor and crack the public keys.

While this not a new thing that poor PRNG or poor entropy lead to weak keys, the algorithm seems to speed up considerably the detection.

Will this force users to use larger keys (abandon 2048 bits keys ?) or abandon RSA sooner in favor of EC cryptography ?

Or maybe this is no big deal, and ... we just should not generate keys on an old Debian after reboot ?

The original 2012 paper the blog references attributes it mostly to using an improperly seeded PRNG, though at least some of the keys had deeper unknown issues:

  We also encountered seven components that we find harder to explain,
  the most remarkable one being a K9, a complete graph on nine vertices.

(vertices being primes, so they found keys using every possible pair of primes from these 9)

If you're using well known software to generate your keys, I wouldn't worry about anything more than proper seeding, which is known to be an issue especially in embedded devices shortly after rebooting.

For the Debian OpenSSL issue you mention though, it's not just after reboot that you have to worry, those keys only have entropy from the PID (15 bits by default) no matter when they are generated.


What Steps Does An Anonymous Artist Need To Take to Retain Anonymity? I read these questions which had great information: How can I keep my identity anonymous as a website owner/administrator? and How much can I trust Tor?, however I wonder if this is too extreme for my situation.

What I mean by this is I am not in a life or death scenario, however I want to keep my artist name anonymous.  Basically, I do not want the fame that comes with the popularity of producing art people like.  If I ever do "blow up," I wouldn't want someone to be able to find my identity through social media or my website, it may hurt my chances of staying anonymous.  With this said, I want to know just how "lax" you can be when keeping your identity anonymous.

Here is my specific question as the last edit was too broad:

If I use my artist social media accounts, launch an artist website (which I pay through a prepaid credit/gift card), and only provide my personal name to the website provider (maybe just use my artist name?), and do all this without a live OS (and TOR/VPN), would someone still be able to find out who I am?  If so, how easy would it be?

That's the basic premise of this question.  I don't want to have to use a live OS because, for example, I don't know if this would even work as I would be uploading my work to the internet for my fans/following.  Plus I would be using my phone often when connecting with fans which wouldn't have the live OS.

If hacking google to gather your phone details is considered a threat to your anonymity then surely the ISP logs must be also - they can relate you to your address much more so than most these other things, in which case a private VPN or TOR must be used. To be honest I would recommend TOR (browser/bundle) anyway, as it enforces the forgetful browser in case you dont remember to..
Other things to look for are GPS/camera tag information if you upload photographs - its appalling the number of site/users that don't remove this information (potentially down to GPS coordinates and time).
A virtual machine with one of the anonymity operating systems (tails or whatnot) would probably be good enough for your purposes though without being too "over the top": Tails - I know you aren't keen on the idea, but it is well suited for anonymity and will work out to be EASIER than manually ensuring these things are in place before using your identity online.
Incidentally, getting those IP logs would take a huge (bribe or) lack of security on the ISP's part or a warrant (It's a non issue with TOR though).
Registering websites and domains are more complicated, unless you can find one that accepts bitcoin payments and dont mind the hassle of that. Prepaid cards might suffice with privately registered domains. But really only you can determine the lengths you are willing to go through.


Eliminating the password in favour of SMS and app based authentication Passwords can often be hard to remember. This leads to people using the same password for multiple websites.

If one was to use an authentication app (or SMS) instead of passwords (for a web application), would that provide a higher level of security than an ordinary password (not considering 2FA)?

If so, could this level be increased eliminating the need for additional hardware by let's say using email as a target for one-time confirmation codes for unknown devices (Of course email accounts can be hacked into but I want to leave this aside for this case)?

Sms or authenticator based login can provide a better security in the sense that you negate lots of attacks like dictionary and brute force. It is not a fail-safe mechanism though.

There are some problems that are caused when you use just sms or app based systems:

If you lose your phone, you can't login till you get a new sim at the very least.
If you lose your phone and is found my some malicious person, it is very likely that your email would be synced on your phone. They can try to login to your website and both email(one of your alternatives) and sms based tokens will be available to the attacker.

As you already mentioned in your question, 2 factor is better than this. If you had to use a single factor, choosing one that is always guaranteed to be known to the user would be better.

EDIT: There was a comment about device encryption and passcodes to protect the system. Majority of Android phones that I have seen use patterns which are not very secure as mentioned on Android SE . Also, whether to use this technique eventually depends on your threat model and assumptions on user's level of maturity. If the users of your app are expected to keep their devices safe, then great otherwise it's a risk.

Opinion: I agree that if they lose their phone, you can have a forgot password kind of prompt but that is still not good enough according to me.


Detect trojan/keylogger/virus on a businees network On a business computer network with around 50 computers, there is a computer infected.

We need to find that and remove it.

I have been running the software below in the suspicious computers, but didn't find anything:

Kaspersky
MarlwareBytes
Spy-hunter
Spybot
Avast!

Is this software is good enough or I need to search for another one?

Now I'm thinking about running a network analyzer.

Does anyone have a different idea or approach?

You provide almost no information: I can barely deduce that you're running Windows from the software you used.

The key question is, how do you know that a computer is infected? This will probably give you the key about how to find out which computer it is.

Lacking information, I'll just list some of the almost infinite possibilities:

some files get accessed and damaged/deleted => you can check access logs where available, or check out network connections using, if nothing else avails, NETSTAT -na in a shell. The victim computer will show connections from the attacking IP.
information gets stolen. If you know this, it is because you found the information where it shouldn't have been. Try disseminating false information, different from PC to PC. If you later find that your corporate website has been accessed using passwordAssignedToEmiliosComputer, you'll know that Emilio's PC is the one to investigate.
the configurations or running images of the PCs are different. You can check the former using REGEDIT, even if it's time consuming, and the latter by running the task manager.
If whatever the virus does implies a lot of network activity, perhaps you can see it with a network analyzer, or by running a diagnostic on the switches, or... at the very least, looking at their blinkenlights (I had to do this once or twice).
Number the PCs from 1 to 50. Disconnect all even-numbered computers and see if whatever symptoms you observed cease. If they don't, try disconnecting the odd-numbered computers. If now they do, you're left with 25 PCs to examine. Number them from 1 to 25 and repeat. You're left with 12 or 13 PCs to examine. Then 6 or 7. Then 3 or 4. Then 1 or 2.


Why is establishing trust in public key cryptography a harder problem than its computational costs? In one of our exams for a non security course, the professor asked for one key problem for public key cryptography and explain why is it a hard problem.

Several students claimed that the hard problem was establishing trust that a certain public key actually belongs to the person who claims that it is their public key.

I believe that the bigger problem is the cost associated with encrypting and decrypting the messages. Isn't that why we do a key exchange in TLS in the first place? To save cost for future messages?

Can someone please explain why establishing trust is the hard part? I believe that having certificate authorities pretty much fixes that problems for us.

Well, having key exchanges and similar hybrid combinations of symmetric and asymmetric crypto solves problem with slow public key cryptography.

On the other hand, while the Public Key Infrastructure (PKI) somewhat solves the problem of verifying public keys, it is very far from perfect. Just check all the problems with CAs that happened over the years. DigiNotar was entirely compromised, Symantec was recently distrusted because they did not verify client correctly, WoSign was distrusted because they backdated certificates, StartCom was distrusted because it was secretly bought by WoSign and did not disclose it as is required, etc.

The problem with slowness of asymmetric crypto is pretty much solved, while the PKI is a huge mess. While we are certainly making headway with things like CAA and Certificate Transparency being mandatory now, we have long way to go before this problem is sufficiently solved. It is also a lot more complicated to solve. There are so many technologies involved already and there will probably have to be more to get to a reasonable point. That is why this is considered a harder problem to solve.


How to configure VPN + Tor + linux as a proxy server? Goal
To hide the IP address using Tor, which goes through a proxy server to make HTTP/FTP requests look like they came from a regular user, not one who uses Tor.
Example
A user requests the website. The request goes through the user's VPN, which then goes through Tor, which connects to a proxy server that finally makes request to the websiteA.
Problem
How to put the proxy server after the Tor? As far as I know, this is not possible with standard configuration of a client machine.
Possible solution
I came up with an idea, which is to intercept all requests on the client machine and send them via Tor to the web server.

User requests https://websiteA.com
My software or user machine configuration takes the request address and sends it via Tor to the web server:
https://myproxy.com?resource=https://websiteA.com
The server gets response and returns it to the Tor network and then to the client machine.

Question
Is my proposed solution viable? Is there a better or simpler solution to achieve the goal?
If I must stick to my solution, what are possible obstacles? (user authentication, POST requests, FTP protocol, etc.)

There is a much easier solution. One can use a tool like Proxifier to set up a proxy chain.

Add Tor as a proxy into the chain
Then add any other proxy

To hide Tor from your ISP, use VPN or add another proxy in front of the Tor proxy in the proxy chain.


Twitter allows the password to be resolved from a stolen cookie. Is that a problem? I recently discovered and reported a security vulnerability to Twitter:

Despite my belief that the report it indeed valid, they replied to me with the following response:

As far as I can tell, this security engineer is talking about protection against cookie hijacking. However that is not my concern at all. My concern is that you can completely takeover a Twitter Account of a user as long as you have the value of his auth_token cookie.

No, I don't claim Twitter has a security flaw leaving sensitive cookie values exposed. There are tons of ways a cookie can be hijacked, and that already puts the victim-user into a dangerous position. However, he can reset his password etc. at any time. But when the attacker is able to brute-force his way into obtaining the password of the logged-in user, hence taking full control of the account (changing email, passwords, etc.), the victim has absolutely no chance of getting his account back.

I even made a video to demonstrate how easy the attack is.

Do you think this vulnerability is valid/critical? Am I or the security engineer at Twitter "wrong"?

Their response is perfectly valid. They are saying that what you found is the intended behavior. There is a usability trade off with security features and they are saying they aren't going to implement one here because the chances of a cookie being stolen is unlikely because of protections they have in place.

They point out that the attacker has to have infected the users computer pretty much to steal the cookie, in which case, they already have their password.

There is one thing they said that i take issue with but its actually to their benefit.

They describe that the cookie can be stolen using XSS if a vulnerability is present but that is not true because their cookie is http-only.
So their site is actually more safe than they are even claiming.

For the future, its best to keep your question generic because this isn't really a good place to disclose something you found on somebody elses website.


PCI Compliance guidance I am in the middle of setting up an ecommerce solution on a commercial website.
My system will store card number in the form of : xxxx-xxxx-xxxx-4000 (just the last 4 digits) and XXX (nothing) for the CVV code. The full details are sent to an external gateway (raven).

I would just like to know what level of PCI DSS compliance I require for my servers end.

Below shows maybe 4 different levels of security options.

https://www.pcisecuritystandards.org/merchants/self_assessment_form.php

Kind regards,

PCI-DSS requires you to be compliant if you store, transmit, or process credit cards.  Although you are not storing them in full, does the full credit card number ever reside (even temporarily) on your site?  If so, you are subject to the SAQ-D.

The only level (singular) you potentially qualify for is the SAQ-A which deals with merchants who have ecommerce or mail/telephone order transactions.

SAQ-A states

Your company handles only card-not-present (e-commerce or mail/telephone-order) transactions;
Your company does not store, process, or transmit any cardholder data on your systems or
premises, but relies entirely on third party service provider(s) to handle all these functions;
Your company has confirmed that the third party(s) handling storage, processing, and/or
transmission of cardholder data is PCI DSS compliant;
Your company retains only paper reports or receipts with cardholder data, and these documents are not received electronically; and
Your company does not store any cardholder data in electronic format.

SAQ-B is for merchants who use card-reading devices.

SAQ-C is basically for businesses that use Point-of-Sale computing systems or virtual terminals.

SAQ-D is for everyone else.

It sounds like card details are entering your system.  Even though your intentions are to use a third party processor, this is not the intention of SAQ-A.  SAQ-A is meant for third-party processing such that the card details NEVER enter your system (think Paypal).


Does WPA2 Enterprise protect against evasdropping from within the network? At home, I have a simple ISP supplied router where I have set up a WPA2-PSK wireless network for our laptops and other devices. While I played around with Wireshark, I noticed that I could use my laptop to see what my tablet is doing in the internet, without the tablet noticing anything.

I think this works because all devices have the same wireless key and there is no way to send packages to one recipient. The recipients are usually kind enough to ignore all the packages that are not addressed to them.

When people visit, I will give them the key since I do trust them enough to perform illegal activities (at least knowingly) or eavesdrop on my traffic. However, they could technically. I came up with the extreme case where Eve would take an old smartphone, enter the key of Alice's network and charge that behind some furniture. It would record parts of the traffic (like DNS requests and passwords in HTTP) and sent it to some server. Alice would not notice this, and even if she finds the phone, Eve could say that she just forgot that she charged the phone there.

Would setting up WPA2-Enterprise mitigate this sniffing problem, at least across the different identities?

It's not possible to see unicast traffic from other users on your wireless network, unless you happened to capture their initial EAPOL registration which contained their session key. Otherwise, even in monitor mode, you're only going to see their broadcast traffic, which is designed to be received by every other device and shouldn't pose a security risk. I believe you've noticed this broadcast traffic and have assumed that you can see all communication from the other devices on your network.

This is a feature of WPA2, not specifically WPA2-Enterprise. Anything else which happens at a higher level in the stack (such as ARP) has no impact on this situation. You can think of WPA2 as analogous to a wired network switch.


SQL injection vulnerability when using prepared statements in PHP I've been studying prepared statements and implemented it in my first login. I used a prepared statement for the SQL query and am wondering if this is enough to ward off most SQL injections?

Since the SQL query is parameterized and I've escaped the username I think it should be ok. The only real issue that I know of (if there are more, please let me know) is the fact that I couldn't escape the password input because of the way Bcrypt verifies it. Let me know if there is a better way of doing this.

<!Doctype html>

<title>password validation</title>

<fieldset>
<legend>enter password</legend>
<form action =passing.php method = "post">

Email:	<input type="id" name ="id" />

Password:	<input type = "password" name="password" />

<input type = "submit" name ="submit" value ="insert" />
</form>
</fieldset>

<?php
// connect to the server

$conn = new mysqli('localhost', 'root', '', 'social');

// check connection
if(mysqli_connect_errno()) {
exit("connection failed" . mysqli_connect_error());
 } else {
 echo "connection established";
 }

if($_POST && isset($_POST['submit'], $_POST['password'], $_POST['id'])) {

$pass = ($_POST["password"]);
$id = mysqli_real_escape_string($conn, $_POST["id"]);
$input = $pass;

$query = mysqli_prepare($conn, "SELECT pass FROM social
 WHERE  email LIKE ?");

mysqli_stmt_bind_param($query,'s', $id );

mysqli_stmt_execute($query);
    mysqli_stmt_bind_result($query, $id);

while(mysqli_stmt_fetch($query)) {

echo "
";
echo "SUCCESS at query";

if (password_verify($input, $id)) {
echo "matching pass" . header("Location: inserh.php");
} else{
echo "not a  match";

        }

    }
}

mysqli_close($conn);

// close the connection

Should I escape input when using prepared statements?

No.

You really don't need to escape input if you use prepared statements. If you want an additional layer of security, use some kind of input filter (eg get me only integers, get me only valid emails, get me only alphanum, etc).

And you obviously should not escape your password, as it doesn't even go into the query.

Escaping really only means that you escape certain characters. This means that ' becomes \' or \ becomes \\. That way, if they are inside a quoted string, they are interpreted correctly. This can prevent SQL injections if the input is inserted into a quoted string, as the attacker cannot exit that string. It doesn't do anything useful if you just apply it to all input. And it's not needed if you use prepared statements.

LIKE instead of equality

You should not use LIKE if you need an exact match. Your use of LIKE here makes it easier to bruteforce your login, and makes it easy to harvest email addresses.

For example, I can sucessfully log in as foobar@example.com:pass with %@%:pass.

As you use a loop instead of just fetching one result - which is what you should do - an attacker can use %@% as a fixed email and just bruteforce the passwords.


Password Encryption For PHP 5.3 or Should We Update to 5.5+? I'm trying to hash passwords for our company site. After testing on a local Apache server that has PHP 5.5.9 and everything working as expected, I went to test on our live server being hosted by GoDaddy. The problem is that when I run my code there, it doesn't work. A phpinfo() statement revealed that the version is PHP 5.3.24.

This presents a bit of a problem because the modern hash functions that I see for PHP, like password_hash(), were written in PHP 5.5 or newer. I don't really see many resources for password encryption for anything older than 5.3.7 and I think it's probably wisest to update.

Are there PHP password hashing functions for 5.3.24 or should I ask my boss to consider updating the server? Aside from accessing the local Apache server, the GoDaddy server is out of my hands except for FTP access, so I have no clue if this is something we can update or not.

Upgrading to the latest supported stable PHP branch is the recommended route plain and simple.

That being said, you've noted that you're with GoDaddy. Which of their services are you using for the project? If it's their shared hosting line, or any line that offers cPanel, upgrading PHP versions shouldn't add anything to current costs. Any web hosting provider with common sense should be able to easily run EasyApache, cPanel's built-in utility for updating and upgrading Apache, PHP and various other pieces of software.

If you're on a VPS, Cloud Server or Dedicated Server, the above still applies if you're using cPanel. If you're running barebones and someone is managing everything from the CLI (nice!), upgrading is a bit more time consuming, though not by much. They'll need to make sure the correct packages are installed before compiling, or, they could simply use built-in packages offered by upstream.

Even if you rely on certain packages, chances are upstream repositories can cater to your needs. If not, there's always building on to an existing package.

That said, if your boss is dead-set on sticking with dated releases, when it comes to PHP 5.3.7+, I'll reference ircmaxwell and paragonie, both of which are available on GitHub.

password_compat - link

The purpose of this library is to "...provide forward compatibility with the password_ functions that ship with PHP 5.5."

random_compat - link

The purpose of this library is to provide PHP 5.x support for random_bytes() and random_int() (from PHP 7.x). This isn't an alternative to password_compat, it's simply another compatibility layer that will allow you to bring features that you're not going to be able to use (unless you're able to upgrade, of course) down.

Note: If you're going to use random_compat, make sure you're using a stable release instead of the master (as noted by the author).

github.com/paragonie/random_compat/releases/tag/v2.0.2


Hiding HMAC-SHA256 in source code and configuration file Would it make sense or provide an advantage of sorts to break a HMAC-SHA256 secret key into two components and hide one component in an applicable server side configuration file and the other component in (closed source, server side) compiled code?

I would choose both half's to be long enough that they individually contain enough entropy to ensure that even if the other half of the key is compromised, the other half of the key remains too long/complex to be brute forced. For example, each half is 32 crypto-sudo-random bytes that are concatenated to form the full secret key.

I understand generally it is not recommended to hide secret keys in source code as source code is difficult to keep secret, but I cannot see anything but advantages by employing this. If the source code key is stolen, the configuration key is still hidden and too long to be brute forced. Alternatively, if an attacker manages to steal the configuration key but does not keep a copy of the compiled source code's key, they still cannot forge the JWT tokens signatures.

Therefore my question is: Am I over looking some sort of obvious flaw in this design or does it truly provide at least a little bit better security? Furthermore, if there is no obvious flaw, is it reasonable to believe this truly does add to the protection of the secret key?

Based on your description you essentially split the secret into multiple pieces and place these in different locations. And these parts are complex enough so that an attacker needs to find all pieces to succeed, i.e. it is not possible to find only some parts and then guess the remaining secret.

If in this scenario at least one of these location is protected with the same strength as you would traditionally protect the full secret then this split-secret system is not less secure compared to the traditional full-secret system and it might be even more secure. If instead you think that just by splitting the keys the system gets more secure and care less about securing each piece than you would have cared for the full secret then the split-key system might actually be less secure.

From your description it is impossible to know how well the parts of the secrets are protected. Source code might be stolen depending on how well protected it is or the code might be reverse engineered depending on how much effort was taken to obfuscate the secret in the code. Similar a configuration file might be easily accessible or not. It is also not known how critical the secret actually is and how much protection it needs. For example in some use cases it makes more sense to change the secret often than to invest too much effort into the long-term protection of the secret. And a secret which depends in part on the source code might be less flexible in such cases.


Should entire domains always be blacklisted? I'm working on a team for an enterprise network security product and we're implementing white/blacklisting as part of the program. We have lists that were taken from a third-party source but nobody remembers the specifications for how these lists were made/compiled. The list contains entries that are whole domains, e.g. foo.com, but it also contains many entries where the domain is the same but the subdomains are different, e.g. abc.bar.com, xyz.bar.com, and so on.

This caused us to think: are there reasons for blacklisting some subdomains of a domain but not the whole domain? This is an important question for us because it will affect how we design the list-checking logic: does the entire query need to match an entire entry in the list to be marked as blacklisted? Or does only the registered domain (SLD.TLD) need to match the registered domain of any entry in the list?

We tried to find literature on this but it was to no avail.

are there reasons for blacklisting some subdomains of a domain but not
  the whole domain?

Yes. For example, a free domain hosting service such as http://000webhost.com would offer their users a domain address such as PICKYOURSUBDOMAIN.abc.com. Here the user using the free web hosting service could pick their own name for the subdomain and multiple users are sharing abc.com.

Malicious user M can now host, let's say, a phishing page on malicious.abc.com and you would need to blacklist it. However, another user might be hosting a perfectly legit website at legit.abc.com on the same domain. Hence, it is more effective to block malicious.abc.com than abc.com.


Is there a difference between the various certificate templates in windows server? On my NPS server which is also a Domain Controller, the Issuing CA has for some reason automatically given the Domain Controller a certificate based on the "Domain Controller" certificate template.

I wanted to give the NPS server a certificate based on the "RAS and IAS" certificate template which it could use to authenticate itself to network clients, but I noticed the "Domain Controller" certificate that was already issued can be used for "Server Authentication". So is there a need to issue the "RAS and IAS" certificate now? Can the NPS server just use the "Domain Controller" certificate to authenticate itself to network clients?

The templates include, among other things, a list of Key Usage (KU) and Extended Key Usage (EKU) fields that you would like in the issued certificate. Outside of very specific Microsoft services, the template field itself is not checked when evaluating a certificate (it is a Microsoft-only field, not a standard), but basically every PKI application will use the KU and EKU fields and in fact must.

Check with the application (e.g, NPS) which KU and EKU parameters it will accept in the resulting certificate. A lot of the certificate templates basically issue Server Authentication EKU certificates making them largely equivalent, but it's still useful to use the right certificate templates for a few reasons:

It makes it easier to determine why that certificate was issued
and which component may be using it
You can lock down the permissions so that only a few people can issue very privileged certificates
You can issue and revoke certificates for each service instead of for the entire server/device

There are downsides though, including trying to force particular services to only use their specific (template) certificate when multiple certificates are installed on the same Windows server. If you're only really trying to provide simple connection security, then re-using one certificate for multiple purposes may not be an issue.


Unknown malware, how to report it and whom to report it to? I'm a professional Windows system administrator, but I've been caught off-guard (or maybe some malware writer has been very clever) and I caught some unknown malware on my home computer (Windows 7 x64 SP1); it must be a very recent one and/or of a rootkit kind, because no antivirus/antimalware/antitrojian/antianything seems to be able to find it, and I've tried quite some of them (and I have quite some experience using them).

It went in two days ago via Internet Explorer 8, which was fully patched, so this is worrying on its own because it clearly exploited some still-unpatched hole (I didn't download or run anything, just opened some web page); it then did some obvious malware-y things like hiding files and icons, flashing system error popups and rebooting the system, and then I found the main executable and removed it... but it left something behind; something that managed to hide so deeply in the system that no tool was able to find it, from popular antivirus programs to highly specific malware detection tools. Of course, I've also checked all the common malware hiding spots (Registry, services, hosts file, browser add-ons, etc.).

How do I know it's there? Google searches (on the Google site, not through the search bar) get sometimes redirected to completely unrelated ad sites, and I have two iexplore.exe processes constantly running in the background (and automatically respawning if I kill them), being launched by nobody else than svchost.exe (as Process Explorer dutily documented) and connecting to obviously fake search sites.

Apart from the obvious question "how do I get rid of it?", what I'm more interested in is how to get some expert to analyze my system in order to find what kind of beast it is, so that it may be stopped before it goes out in the wild... if it already hasn't.

Edit: looks like it actually was a rootkit; I finally got rid of it by rewriting the MBR and boot sector of the system drive. Don't know yet what the boot code was actually loading, some executable must still be lingering around... but at least it's inactive now.

If you can find the offending executable or dll, one thing you can do is to upload it at https://www.virustotal.com. Try even the svchost file if you feel it's suspicious.

It will show you how many antivirus engines detect it out of a huge list, and will also forward your sample, if it fails to be detected, to antivirus companies for further processing and signature development.


How to regain access to the server? I have a Debian server with KVM available 24/7. It was recently broken into and its root password changed.

My hosting provider has restored my access and helped me change the password. But in the general case, how can I protect myself from hacking and make sure this doesn't happen again? Also, how can I regain access to the server itself?

If an individual could get enough control of your server that he could change the root password, then he basically owns the machine and keeps on owning it even if you changed the password back:

The vulnerability through which the intruder came in still exists until you find it and fix it, so he can come back at will.
The first task any half-witted intruder performs upon entering a machine is to plant a few extra accesses in case the sysadmin tries to get away with a few simple cleaning procedures on the machine. This is called a backdoor. People with root access can plant backdoors which you will never find from the machine itself (because the backdoor includes a kernel modification whose job is to hide the backdoor).

Therefore the only sane thing to do with your machine is to do what is traditionally called in these parts "nuke it from orbit". You are due for a reformat + reinstall from scratch. Sorry. Tough luck. For your next install, try to choose stronger passwords and to apply security updates more often (you should aim at daily updates, to minimize risks of compromise).

At least, the key advantage of IT over Medicine is that in the field of IT, you do not get sued for reformatting patients.


Using HTTP Strict-Transport-Security with preloaded Lets say I have a site that accepts example.com and www.example.com
I want to enable HSTS and use preloaded on this site.

I've read that I need to be very careful because all the sub domains need to support https etc.

My question is if my entire domain (example.com) including all subdomains gets added to the HSTS preloaded list?

Lets say I have internal.example.com on another server completely running a totally different site without HSTS enabled, not even using https at all. Would this site also get checked for the preloaded HSTS list if the main domain is listed?

To get your site preloaded by the browsers you must submit it to https://hstspreload.org/. The site there clearly states:

  Submission Requirements ...
  3.Serve all subdomains over HTTPS. In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.


Dump linux password in clear text Is it possible to dump a Linux password in clear text format?
In Windows it is possible to do so using "Windows Credential Editor".

Yes, it's possible.

The WCE product you reference works by scraping passwords directly out of memory.  That method also works in Linux; a rootkit which has unfettered access to memory and can hook system calls can extract passwords from there - consider this example, which can steal username and password pairs

Both solutions are limited in that they

can only capture passwords as they're used - someone has to log in to have their password compromised, it's not dumping the authentication store for everyone.
require the OS to be hooked - let's just say compromised - at a deep level.


Why don't security conscious websites use a combination of private unique identifier and password to secure their logins? To be clear when I say "private unique identifier" I mean an identifier, which is not stored on the database for the website, it would be hashed in combination with the password and a good salt in the hash table for login information to each account. And when a new user signs up or has forgotten their unique identifier a new one would be emailed to them, and said email along with all trace of the identifier would be deleted from the server after hashing it with the password and storing them. To clarify further you couldn't use a display name because then it would be connected to the account on the hash table, and you couldn't use an email address because the server needs to keep that unencrypted in case you lose your account credentials and you need to be sent a reset link. This would be something like the initials of your name with a unique identifying alpha-numeric or numeric code tacked on to the end which is too long to be brute-forced.
Now the reason why I think this should be an obvious idea for account security. If you were a malicious actor who managed to steal the entire hash table with salts and related account information from a website then there are certain attacks on the said hash table you could use to gather login information. This includes hashing the most common passwords list in combination with the salt values to find the easiest logins. This attack obviously wouldn't work so well on accounts with safe passwords, but I'm going to look even further for maximum security even for accounts with bad passwords. If you have a private unique identifier hashed with the passwords, then dictionary attacks using common password lists wouldn't work because they don't have the unique identifier, and it's not user-chosen so there would be no way to find it.
I've gone over this method a few times in my head and I feel like it's pretty solid, and it has probably already been named somewhere, but I'm not sure what it would be called and I couldn't find it. One thing I know for sure is none of my accounts use a method like this. Please let me know what the name of this practice would be, what attacks would work on a security method like this, and why more websites don't use a method like this. The only reason I can think of is that asking users to keep track of a unique identifier in addition to their passwords all for a security method that only adds so much to passwords is more security than most websites care to use.
Thanks for any and all answers.

I am unaware as to a name for this model, but would say that the main reason for lack of uptake is its unwieldly nature if the user is not already employing a password manager.
In this setup the Private Unique Identifier (PUI) appears to be acting as a second password, one that is specified to be secure in the event of database breach. Assuming the PUI is of recommended length for a strong password (using Protonmail's of 15 characters as an example) this will be nigh impossible for end users to remember for multiple sites. As such they would have to use a Password Manager to effectively use this system, but in the event they do this they can already use passwords of sufficient length and randomness.
In addition the PUI is not a 'full' implementation of MFA as the PUI is not a different type of proof (such as something you are like biometrics or have like Authy app). Consequently I do not think the added security is as great as encouraging users to use 2FA.
The other, more mundane reason is that this change would involve changing many tables or files (if using NoSQL) in your DB! As to implement this you may have to change the Primary Keys of tables it could be a very hard security addition to add to an existing site.
As for attacks, as (assuming I understand the concept like you) the PUI acts as a second password, it would be suspectible to the same attacks. If it is also created with your initials or another deterministic prefix this might make it easier to break.


Windows and BlackBerry device for learning penetration testing I want to buy a Windows Phone 8 and a Blackberry (BB) device for practicing penetration testing of mobile applications (of course, Windows and BB apps).

I am asking for appropriate devices. I don't want alternative of emulators please  I have tried emulators concept but it does not suit well as is the case with Android devices. It is cumbersome to set up Windows emulators as my laptop does not meet the specifications.

Can anyone suggest a good Windows as well as Blackberry phone that best suits for pentest of mobile apps?

For Windows Phone 8 I would buy a Nokia Lumia 520. It's cheap, I guess it can do anything that other WP phones can do. Why buy something expensive? Maybe if you need more memory or storage?

For Blackberry, which OS? There are many versions, each with its own problems I guess.


Why do client certificates not protected against improper server certificate validation I understand the question of client certs and MITM attacks has been asked several times, but I don't believe this specific scenario has been answered.

It was my (seemingly incorrect) assumption, that the presence of a client cert would allow the server to ensure the client was correctly consuming its server certificate and not a fake one presented by a MITM (by receiving a response from the client that only the client should have sent, and that only the server could have sent to the client).

Some testing I have done shows that if the client does not correctly check the server certificates CA, then you can MITM.

I understand that a failure on the client to not correctly identify the server certificate is the point of error, but what can a server do to ensure a client is fulfilling this obligation?

The certificate-based client authentication in SSL takes the following format: the client shows its own certificate chains, and computes a signature over all the handshake messages previously exchanged. These handshake messages include the message where the server sends its certificate chain to the client.

In that way, the server can make sure that the client (the one who owns the shown client certificate) really saw the correct server certificate, not a fake one. In that sense, requiring certificate-based client authentication can prevent a true Man-in-the-Middle (if your "testing" shows otherwise then either you broke SSL, or there is something subtly wrong in your test situation). However, the Devil is in the details...

A MitM attack is a simultaneous double impersonation: the attacker runs both a fake server (when talking to the client) and a fake client (when talking to the server). A true MitM is prevented as long as either the client or the server correctly verifies the certificate from the peer, which entails validating the certificate (verifying that it has been issued by a trustworthy CA, and so on) and also using the name in the certificate as identity of the peer (a client connects to some IP address but the certificate is about a guarantee for a server name).

However, there are other kinds of attack which, while not being MitM in a strict sense, can be troublesome. For instance, if the client does not perform a correct validation of the server's certificate, then the attacker can run a fake server and talk to the client. The genuine server is not involved at all ! That kind of thing is not a genuine MitM, but can be sufficient to recover some client secrets (the client believes that it connected to the correct server, and then sends sensitive data through the tunnel).

There is nothing that the server can do to ensure that a client always validates the server's certificate properly -- in particular when the server is not contacted at all, because the client is connecting to a fake, attacker-operated server. At best, the server can make sure, through certificate-based client authentication, that the client for this time uses the correct server public key for its cryptography.


Save private messages encrypted in database I'm not sure if this question fits better in StackOverflowSE or CryptoSE but i think this is the right place.

In an online community portal I want to save users' private messages encrypted in a database so the information can't be leaked if someone gets access to the database. But I have no idea how to manage the keys.

When a message is sent it should be saved encrypted in the database and should only be decryptable if one of the participants is requesting the message. The key obviously must not be saved in the database as that would make the whole thing pointless.

The way I came up with is to save the message with a symmetric-key algorithm and save the key encrypted with a public-key algorithm for each participant (each user has a public key).

When a message is requested it is decrypted by using the user's private key to get the symmetric key. However I have no idea how to create/save a private key. It must not be in the database and due to the application being multi-platform (web, mobile access) I can't save it on the user's device and must be generated on the fly using a constant which comes from the user and is not saved somewhere in the database. The only constant I can come up with is the user's password. But in case the password is lost/forgotten there is no way to access the messages anymore.

My question: Is there another way to accomplish this? Or do you know of another constant which is still private?

Edit/Update:
Thanks for your answers. Here is an update:

What about saving the private key in db encrypted with a random string that is sent to the user in a mail once at registration? The user is advised not to delete that mail. If she still does (seems quite likely) then I can blame her, well no j/k, but that would be at least one way to recover the messages.

Here a sub-question: The application can only be accessed via HTTPS or TCP/IP+SSL API. Is it save to en-/decryt the message on the server and send it in plain over SSL? Else I would have to look for implementations (like GPG) for all platforms (browser, mobile, desktop). This requires to store the private key in ram for the time the user is logged in (password is sent at session start/login). Sure if someone gets write access to the server (alter the application) or read access to the ram (o0) he could sniff the keys but I don't think this is likely.

The message must be *en*crypted on the server (means sent in plain) anyway as it possibly needs to be pushed to mobile devices by the server. (It's not important whether that's safe or not, I want to make sure noone can use a database dump - not if Apple or similar can read it while being delivered).

Probably I don't need any of this as my users most likely won't sent secret messages to each other but in case of a leak they won't be glad. It's a community for local students and you never know what bored CS students are up to ;).

If the only way to do password recovery involves answering a question you could encrypt the private key once with the password and once more with the secret answer and store both encrypted versions in the database. Then if the user forgets the password and uses the secret answer for recovery you can access the private key and re-encrypt it with the new password (for normal usage). If the secret answer is being changed, the password should be requested and so the version that is encrypted with the answer can be re-generated.

This does have (at least) two issues. The 'secret' answer will often be not that hard to crack. This could be partially addressed by using PBKDF2 with a very large number of iterations (since this option would be used infrequently).
Another problem is, obviously, if for some reason you want to reset a user's password manually (i.e. they have convinced you of their identity without knowing the secret answer) then you won't be able to recover the messages. But depending on what compromises you are willing to make it could still be useful despite these problems.


How to fix this broken crypto protocol? I am considering a protocol where you upload a one time pad to a server, using public key encryption and then the result (using the pad) is sent back in plaintext:

Alice uses Bobs RSA public key to request a file
Bob replies over RSA that it is 7MB
Alice uploads 7MB of random bits to Bob encrypted by RSA
During this, Bob is responding with the plaintext of (file xor random data)

So I tried to run through the basic attacks to see if this was secure and I had to add:

The response must be divided into blocks and each block signed
otherwise Eve could modify the data on the way back from Bob to Alive

but then I realized Eve could modify the encrypted OTP on the way to Bob - this would not allowed her to edit the message reliably but to corrupt it. So we need to add:

 Alice should provide a checksum for each block of the OTP sent

So I tried to harden it up a little bit and I was wondering if there are any attacks against this?

I am assuming you are making a toy protocol for the fun of it -- learn about crypto, have fun implementing something, but understand that this toy scheme is probably flawed and that if you have sensitive data you should use well-known vetted protocols, not toy schemes you just came up with.  (If not see reasons to not roll your own ).

First, RSA just describes the scheme c = m^e mod N where you encrypt a message m with a public key (N,e), and decrypt with private key pair (N,d)via m = c^d mod N.  You should not encrypt your OTP with RSA -- it will be very inefficient and there are many attacks against RSA without proper padding.  You really should always use padding schemes like OAEP (specifically PKCS #1v2).  RSA is expensive for long messages, in practice you always use hybrid encryption.  That is use RSA to encrypt a randomly generated key for a symmetric encryption function like AES (other encryption functions are fine, just chose AES for concreteness).  So Alice first sends ERSA(RSA-PubKey, OAEP(Random-AES-key)), where RSA-PubKey = (N,e) and ERSA(RSA-PubKey, m) = me mod N.  Then she sends the AES-encrypted secret data EAES(Random-AES-Key, Secret-Data), which just means Secret-Data is encrypted with AES and the recently generated Random-AES-Key.  Then the receiver first decrypts the AES-key using RSA with the private key (N,d) and then undoes the OAEP padding, and then decrypts the message using that AES-key to get back the secret data.

That said, checksums should not be used to prevent tampering of a message in transit.  If an attacker can guess a message, they can calculate the checksum, and then tamper the encrypted message to alter both the message and checksum.  For example, if the message was encrypted with AES-CTR mode and the message is m = "Transfer $1000 from Alice to Bob's account." and uses MD5 hash as checksum h=b2a26c14a029b0a2aadba4fa2ecd32d2.  Eve could calculate xor between that message and m' = "Transfer $9999 from Alice to Eve's account." which has the md5 checksum h' =308b23cb47b0efff365c2593e0a005d7 and then XOR the encrypted message with m XOR m' and the encrypted checksum with h XOR h'.

Message Authentication Codes are the way to provide integrity that your message wasn't tampered.  These are essentially checksums that intrinsically rely on a shared secret key.  There's always a question of how to MAC, should you Encrypt-then-MAC -- (send E(Data) ++ MAC(E(Data)) or MAC-then-Encrypt (send E(data ++ MAC(data))) or Encrypt-and-MAC (send E(data) ++ MAC(Data)), but Encrypt-then-MAC is the consensus best option though other schemes can be secure for certain ciphers.

There are other issues (e.g., generating OTP is quite expensive and uses a lot of entropy which could be problematic).  I also don't see what the OTP step gains in security -- e.g., if the RSA step is compromised all the other data is compromised as well to any eavesdropper.

Furthermore, the one-time pad only has provable security when the pad is used exactly once.  The many-time pad is notoriously weak as c1 XOR c2 = m1 XOR m2.  E.g., assume Eve can't send requests for files to Bob, that there's some undisclosed authentication function that verifies Alice's identity to Bob before Bob will respond back with a file encrypted via a OTP).  If she observes Alice ask for file1, sending an encrypted 7 MB OTP (OTP1), she could then request file2 (only 6 MB) sending back the same first 6 MB of OTP1.  Bob then replies back with file2 XOR OTP1, leaking to Eve the XOR of file1 and file2.  So along with the OTP that is MAC'd, there must be a scheme with a random nonce (generated by the server) that must be included with the encrypted OTP, that is verified (to make sure the encrypted pad wasn't replaced with a previously used OTP).


What certificates are needed for multi-level subdomains? I'm working on a web site with a several levels of subdomains. I need to secure all of them with SSL, and I'm trying to determine the correct certificate strategy.

Here's what I need to secure:

foo.com
www.foo.com
Any combination of city.state.foo.com. (These are US states.)

My understanding is that a wildcard certificate can only cover one "level" of subdomain. According to RFC 2818:

  Names may contain the wildcard character * which is considered to
  match any single domain name component or component fragment. E.g.,
  *.a.com matches foo.a.com but not bar.foo.a.com.
  f*.com matches foo.com but not bar.com.

What I think I need is the following certificates:

*.foo.com, which will match, for example, foo.com, www.foo.com. (Though I'm not clear on whether *.a.com matches a.com by itself.)
*.ny.foo.com to match new-york.ny.foo.com, buffalo.ny.foo.com, etc. I will eventually need 50 such certificates to match all the states, once our site expands to serve them all.

My questions are:

Is this scheme correct? In the scenario above, if a user visits ca.foo.com, will they get the certificate for *.foo.com or for *.ca.foo.com?
How can I ensure that users see all of these subdomains as legitimately owned by us? For example, if a user visits foo.com, then mountain-view.ca.foo.com, and those are different certificates, will they get a warning? Is there some way to assure their browser that these certificates share the same owner?

Theoretically:

a * matches exactly one level (hence *.foo.com does not match foo.com)
but you can have several * in a name

Hence, if all SSL implementations faithfully follow RFC 2818, you just need three certificates, with names:

foo.com
*.foo.com
*.*.foo.com

and, if the implementations are really good at sticking with RFC 2818 and the intricacies of X.509, you could even use a single certificate which lists the three strings above in its Subject Alt Name extension.

Now, theory and practice perfectly match... in theory. You may have surprises with what browsers actually do. I suggest you try it out; some example certificates can be created with the OpenSSL command-line tool (see for instance this page for a few guidelines).


Port scanning legal or not? Is port scanning legal ?
In which countries ?

my option :

I think port scanning is like a short-walk( or a long-walk) in the neighbourhood, just curious about neighbours are up to.

I think that port scanning must be legal. Sometimes you could find an interesting  website  or ftp etc.
( what if there was not google,yahoo,duckduck ? to search the web )

and it is up to the administrator to use passwords to protect something that does not want to see anyone else.

Port scanning is more akin to taking a walk around the neighbourhood and trying every handle of a door and every window to see if it's open, to see if the neighbours have left anything available for future investigation or exploitation/theft.

The walk you describe would be more of a ping sweep - just see if the host is up (or house exists).

Regarding legality, intent plays a big part, and whether you have permission of the target (white-hat vs black-hat). Consult a lawyer.


git file signing with eID Background story; government issues new IDs (eID) which can hold certificates and you can sign documents with it, using card reader and some software that signs document itself (while I do research lots of sites address this software https://store.ardaco.com/en/13-qsign-premium) + government issues software also but is not documented in english (worthless mentioning here).

I have a relative which is a doctor and faces problem with storing dozens of documents (each patients visit) in case of inspection. With new eID there is a legislation change that companies (doctors) can store documents using hard drive but all documents must be signed with eID (data integrity + timestamp).

Software (qSign) above solves one problem - signing the document(s), but does not solve recording archives (kind of like version control).

So to solve both problems I googled around and there is a possibility to use git + GPG to sign commits/tags.

When I sign "commit" does git signs file itself or just the information about commit? Is it possible to sign file also?

Is using git viable or I should just drop the idea?

I called government about the issue (did not propose using git etc. because of "IT language barrier"). Government only requires that if doctor uses option to store / archive documents on hdd it must be properly signed by eID. So when inspection comes then IT guy can confirm yes Mr. X T signed this document at 12:00am 24/1/2015.

edit

From user guide (eID client) I can translate.
- certificate propagator
Certificate propagator after inserting eID card in card reader challenge user to insert PIN code. After valid PIN code is inserted certificates are copied to Windows Certificate Storage.

So I assume I can use these certificates to sign documents as I please.

Taking a look at git signing process, it says that only commit information can be source verified by this method. After version 1.8.3, git can also sign commits and merge requests.

The person who execute those operations provides the gpg key password for signing, and everyone that looks at the commit, tag and merge can see if it comes from a "trusted source" by checking the public part of the gpg key.

However, this solution does not encrypt individual files. It's just for checking that commits are actually from a trusted source. What could help you is to "enforce" commit hooks usin eID on your relative's document repository.

tl,dr: Git does not encrypt individual files so, it will not be a viable solution to you


Is WebRTC still leaking my IP addresses in incognito or private browsing mode? WebRTC can leak your private IP address, even though you are using a VPN, from what I learn here.

Am I protected against this information leak affecting my privacy, when I'm using the incognito or private browsing mode in my browser along with a VPN connection? In other words, is my private IP address hidden from the websites I visit?

Unfortunately both internal and external IP addresses are still exposed even when you're browsing in incognito/private mode. In your case not only your internal network IP-address and the internal VPN IP-address will be exposed but also the external ISP IP address.

You can test it for example here:

https://ipleak.net/ (seems offline)
https://www.browserleaks.com/webrtc

Chrome and Firefox leak this information even in incognito/private mode. Although there is a fix:

For Firefox

https://addons.mozilla.org/En-us/firefox/addon/happy-bonobo-disable-webrtc/

For Google Chrome

https://chrome.google.com/webstore/detail/webrtc-leak-prevent/eiadekoaikejlgdbkbdfeijglgfdalml?hl=en


Is it possible to login to accounts if you have access to an android phone? Similarly if you have access to a PC you can steal session cookies which allows you to login without password and without the login showing in login logs.

If one has access to an android device is it possible to do something similar, I know apps dont work the same as web apllications but still is there a method similar.

This is purely for education purposes.

Like @Steffen says, mobile apps work very similar to web applications. Sometimes they consume the same APIs and use the same authentication/authorization scheme (e.g. API keys). This information needs to be stored somewhere, especially for apps that stay persistently logged in.

Most apps store sensitive information in the app's protected directory in /data, which other apps cannot read without root access. You may be out of luck unless the device is rooted, there is an RCE vulnerability in the application, the app's comms are not properly encrypted, or the target app allows debugging.

Additionally, most modern Android devices use user-data encryption at rest. So, a powered off phone (or even one with a custom recovery) is no good for circumventing permissions and recovering data.


Is there ever a good reason _not_ to use TLS/SSL? While writing an answer to this question on Server Fault, a thought that has been bouncing around my head for quite some time resurfaced again as a question:

Is there ever a good reason to not use TLS/SSL?

To further elucidate the question, I'm asking about the specific case in which things have been configured properly:

Performance:

Time to First Byte has been optimized.
The cipher list is small enough to avoid multiple roundtrips from server to client.
For mobile web applications, 2048 bit RSA server keys have been used as opposed  to 4096 bit keys to lessen the computational load on clients.
SSL sessions have a reasonable lifetime to avoid regeneration of session keys.

Security:

Perfect Forward Secrecy
Hardened Cipher List
Don't use obsolete and insecure protocols like SSLv2 and SSLv3 (if possible; not using SSLv3 means that IE 6 can't access your site).

If done properly, is there ever a good reason to not use TLS/SSL for TCP communications?

The main issue with HTTPS everywhere is that it basically makes caching web proxies useless (unless you have trust the proxy and have it impersonate sites for you, but that doesn't work with certificate stapling and is possibly illegal in some jurisdiction). For some use cases, like for example the distribution of signed software update, HTTP makes perfect sense. If you have e.g. a hundred workstations behind a corporate proxy, them downloading update with HTTP will mean for all but one it will be delivered off the proxy cache. That will be a lot more efficient that each of them doing it over HTTPS...

In short, HTTP makes sense as a transport layer if another mechanic is there to verify the authenticity and integrity of the content, and if confidentiality is of little importance...

For web browsing by actual human beings, I find it very hard to justify not using HTTPS in this day and age.


how an iframe can cause xsrf? I know how a form tag is prone to CSRF which does not use any token (or any other challenge-response mechanism) but I was wondering how an iFrame can be used to cause XSRF attack and what would be the mitigation techniques?
Following is the code example:

document.write('<IFRAME SRC="https://somedomain/abcde;src=;type=;cat=;ord=;num='+ a + '?" WIDTH=1 HEIGHT=1 FRAMEBORDER=0></IFRAME>');

The code example, you gave is a cross site scripting vulnerability, because it allows the execution of arbitrary JavaScript, assuming "a" is untrusted:

a = "\"); evil(); document.write(\""

A malicious site can use an iframe to exploit a vulnerable site via CSRF:

In a typical CSRF attack, the browser is tricked by a malicious site to submit a request to a vulnerable site. The browser will include the cookies for that site, thus the request is authenticated from the point of view of the vulnerable site.

While there is a number of ways to trigger GET-request, cross site POST request are usually created by submitting a form. While JavaScript can be used to trigger the submission automatically, it cannot be used to hide the result page. So on a simple POST-based CSRF-attack the user will be warned after the fact.

So the trick is to put the malicious auto-submitting form into an invisible IFrame. Therefore the user will not see the webpage showing the submission result.

A related attack is click-jacking: The vulnerable site (e. g. Facebook's like-button) is loaded into a transparent iframe and JavaScript is used to scroll it to the appropriate location and keep it positioned at the mouse cursor. If the user tries to click on anything on the malicious site, it will click on the transparent iframe instead.


What are the security risks associated with PDF files? What are the security risks associated with PDF files?

There is, of course, the general risk associated with any type of file: that whatever application is used to read it will have a bug that can be exploited by certain byte sequences within the file, thus crashing the system, or worse, executing arbitrary code.

That's a pretty standard security issue.  Anything extra on that general risk specific to PDF files?

Beyond the above general risk, what other risks are associated with PDF files?

Since PDF files can contain javascript (JS), what risks does that pose?  Or is it well locked down for all major PDF viewers/editors (Adobe Reader, PDF-XChange, Sumatra, Foxit, Nitro, as well as the internal viewers in Firefox and Chrome)?

Are there other risks as well?

Do some PDF files have "call home" routines that can send a ping (or other data) to a server when they are opened or edited?

What about edit-protected PDF files or password-protected PDF files?  Anything special there?

I'm most interested in answers that are relevant to Windows and Android, but am also interested in those relevant to linux, unix, OS X, and iOS, as well as OS-agnostic answers.

One PDF-specific risk is that Adobe and third-party reader extensions are supported: your PDF viewer may have extra modules loaded, or may require them to open certain documents. Examples include:

Adobe LiveCycle Rights Management ES4
Time limited PDFs for which there are commercial products

Both of these endeavour to constrain digital document use. At best, such features increase the attack surface, and at worst may deny you access to some of your files, report on your activity or otherwise take liberties with your privacy, documents, computer or network. (Sound familiar? Seems analogous to a browser and web page that needs Flash  or a similar proprietary plugin.)
See also this question which covers PDF phone-home capability. Javascript, embedded multi-media (including, but not limited to Flash) and Xobjects (external streams) are at least some of the ways to achieve that.
Some less-obvious risks associated with, but not entirely specific to PDFs:

PDFs can contain attachments, though not all readers support this, and those that do don't always visually indicate their presence. These can be any type of file, including another PDF. An encrypted PDF (commonly RC4 or AES) is identifiable as a PDF (only the data streams are encrypted, rather than the file as a whole), the presence of attachments is not evident in this case. Behaviour is restricted on some platforms at least, see Adobe's KB 331371 and KB 328671. (I consider this is a potential risk because it comes as a surprise to many people, and it may be used for stealth transfer. The "Peachy" worm is a proof-of-concept example)

Misplaced faith in native "security features" such as no-copy, no-print, no-edit. These are effectively discretionary controls, at the discretion of the viewer software itself.

The structure/layout of the PDF format is quite loose, and PDF lends itself to use and abuse as a chameleon or polyglot format (PDF), see Corkami's examples here:
http://code.google.com/p/corkami/wiki/mix?show=content . This show files which are simultaneously PDF, native binary executable, .jar and .html by using similar "slack" in those formats.

Metadata may leak information about the document origins or history. Sloppy redaction is also problem.

Support for rich content (multimedia via Flash, embedded fonts) and browser integration facilitate attacks on client-side software components beyond the reader/viewer itself

See the Acrobat Application Security Guide for further details.
There are two types of PDF passwords, in Adobe terminology the user and owner passwords. The user password is used for encryption, the owner password is used for discretionary access control. These may be augmented by proprietary controls via extensions.
Password protection can be secure (using RC4-128, AES-128, AES-256 with good key derivation), but RC4-40 is still supported, and Adobe fumbled the ball with the initial AES-256 implementation in Acrobat 9/PDF 1.7 by omitting iterations in the KDF:

While this allows for 256-bit AES password protected documents to open faster in Acrobat 9, it can also allow external brute-force cracking tools to attempt to guess document passwords more rapidly because fewer processor cycles are required to test each password guess.

Applies to Acrobat 9 PDF 1.7 ExtensionLevel 3 (2008), fixed in Acrobat X PDF 1.7 ExtensionLevel 8 (which became ISO PDF 2.0). You can read some background to that issue in Sin 21 of 24 Deadly Sins of Software Security. PDF version specific details can be found here:
https://www.pdflib.com/pdf-knowledge-base/pdf-password-security/encryption/
In summary:

PDFs are feature rich, and the implementation potentially complex, both of which contribute to an increased attack surface
support is multi-platform and since it continues to be the de-facto document format, approaching ubiquitous, making it a popular target. ISO standardisation of PDF 2.0 furthers this.
PDFs provide a vector for attack payloads (Javascript, multimedia formats, fonts, arbitrary attachments) both by design, and by accident

As with Flash, I've long had concerns about Adobe Reader's approach to browser integration which can do nothing positive for the attack surface of a browser. With native browser support for PDFs this problem is shifting away from being an Acrobat issue at least.
The result of the above (combined with the near legendary bloat of the canonical PDF reader) can been seen in the CVE statistics for Acrobat/Reader (though note there are several other Acrobat/Reader variations with separate counts, and those stats stop around 2018).


Heartbleed - is this scenario possible? how bad would it be? Let's make the following assumptions:

A trusted root certificate was being served with a vulnerable version of OpenSSL.
Prior to public disclosure, a malicious entity was aware of and exploited the heartbleed vulnerability
Said malicious entity attacked and gained the private key for the root certificate
I don't have an affected version of OpenSSL on my server, but I have a certificate signed by the compromised root certificate

Presumably, at this point, the CA would revoke their root certificate, and any certificates signed by it would have to be re-issued, correct?  Once the root certificate was revoked, the potential for damage would be limited to clients that didn't update their trusted root bundle, correct?

What about last week?  A compromised root certificate would have allowed an attacker to create a certificate for any domain, not just one that had been signed by that certificate, right?  There wouldn't be any additional vulnerabilities for my domain because its certificate was signed by the compromised certificate, right?

And, as a bonus made up of complete speculation, how likely do you think it is that this vulnerability has been found and exploited prior to public disclosure?

They are two different services, that are not related.

PK Signing service

These keys use the CA's crown jewels.
They are protected as much as they can.
If they are lost, they will be Out of Business
So they use network segmentation, firewalling, HSM's, armed guards, whatever it takes to secure them.

Normal SSL website using a signed key (possibly but not necessarily from the service above).

Impact of compromise - embarrassing, reputation damage but not critical.

So, they 'could' choose to combine these two services, using the same key on the outside of their website, but as @StephenTouset says above, "It would take an astonishing amount of incompetence"


How secure is a password made up of three or four three-letter words? According to this, a password such as dinwryran is secure against a brute-force attack. Is this true? If not, why?

I would have to disagree that his claim of three 'three-letter' word is secure. In his article he says:

So - 500 x 500 x 500 = 125,000,000 (one hundred and twenty five million) possibilities.
Maybe that doesn’t sound like a lot - but if you could check 20 of them every second, 24 hours a day, you would need roughly 60 days to get through them all!

First of all, password cracking tools and combination of hardware can crack way more than 20 per second especially if the list of combinations is pre generated. On top of that, if a hash of these passwords are retrieved then an offline cracking attack can be performed which means the attacker has all the time in the world to try to crack them and if it actually did take 60 days, to a motivated criminal that is nothing.
The simple fact is that 9 alphabetical characters is just too short in the present day.
12 characters expotientally makes it more difficult but using only alphabetical  isn't the best.
End of the day, I like to use a password manager and generate unique 20+ character password with alphanumeric, special characters and mixed case.


Can someone please briefly explain HIPAA compliance? I worked in web hosting for several years, particularly security.  I am familiar with PCI compliance and I would say the "short and sweet" guide to PCI for an eCommerce store is as follows:

Client goes to the bank and gets a merchant account.
Merchant tells the client to use some random "authorized scanning vendor" (ASV) (i.e. TrustWave) to scan the server and site.
The ASV runs an automated scan that finds a bunch of random "vulns" such as old versions of software or the ability to list directories.  The better ones actually scan the site for XSS and other web vulns.
The client sends me a PDF depicting all the vulns.
I lock down the server & report all the backports.
The ASV runs the scanner again and signs off on it.
PROFIT!

The way I see PCI is a "Cover Your Ass" type of thing.  An authorized ASV signs off saying the site is "secure" thus deflecting some responsibility off the client.

With that being said, how does HIPAA compliance work?  Let's say Joe the doctor came to me and said "Make my office HIPAA compliant."  I know security but where would I start from the legal sense?  Are there any "Authorized" HIPAA organizations that do scans and sign off that the organization is secure?  Are there any hard coded rules (i.e. passwords must expire BEFORE n days)? Could I even help Joe out or must I be certified in some way?

Please briefly explain HIPAA compliance in the practical sense.

I am not doing anything for a client, I am just curious since this topic is very ambiguous and I have no experience in it.

HIPAA compliance is a little more complicated. There are minimum security standards with regards to configuration in the network, systems and physical security domains which must be met before your organization may be certified "HIPAA Compliant". There are too many to list here, but to give you an idea, here's a few line items.

On the network side, such minimum security standards include:

Separate VLAN for medical records / medical device traffic
Access Control Lists with default-deny, restricting access to medical VLAN
Default-deny access policies (users must be explicitly granted access)

On the systems side:

Workstations auto-lock their screens after X minutes (usually <15)
Users are required to change passwords every X days (usually 90)
Granular permissions for network shares, with default-deny

On the physical side:

Physical access to network/systems maintenance areas must be secured through lock & key at minimum, two-factor preferred
Security cameras must monitor building entrances and server/network rooms

On the administrative side:

Terminated employee credentials must be revoked same-day
Employee background checks must be conducted, by a vetted agency

...and the list goes on-and-on. That's just the tip of the iceberg.

Generally, the network/systems security requirements follow the NIST SCAP guides: security checklists of "best practices", which may be found here:

NOTE: Large parts of these websites are unavailable during the government shutdown.

EDITed to add:

In a legal sense, you'll need to ensure that you follow all the guidelines. This is the "due diligence" for HIPAA compliance. See here

Note that if the Department of Health & Human Services audits you and finds security compliance issues, your organization may find itself on the wrong side of more than one regulatory body.

EDIT 2: Also note that "certification" by a third party does not absolve the business entity from any responsibility relating to HIPAA compliance.