Fixes poor passwords, accessibility and storage problems with highly secure way.
What does that even mean?
Instead it regenerates the password each time.
i.e. password for HN may be: some trait of HN (domain?) + some salt + your identity (cert?) to always produce the same password.
I didn't understand it all from the site, the explanations and broken English didn't really elucidate. But... if my understanding was right, I wondered about how to handle cert changes or key rolling, etc. There seemed to be a mentioned mechanism for this, but again I didn't really understand that from the description.
Gist though: No generated and stored passwords, but a pattern to always generate the same password for a given site.
How does it deal with stupid password format restrictions?
How long does the retrieval of a password take? Sub-second? 10 seconds?
It is a password manager too but with an alternative approach.
>> "Fixes poor passwords, accessibility and storage problems with highly secure way." >> What does that even mean?
Generates strong passwords by default, you can access them anywhere with it and does not need to store anywhere.
But you have to carry the database with you anyway and have to store somewhere. So what's the point of having database with everything but passwords?
And you still need the database encrypted, because you don't want to give the attacker your usernames, emails, recovery answers and other stuff, do you?
But you probably want to keep the meta info of what sites you have access to secret to.
So I don't know why this is better than simply use the certificate to encrypt the database.
But maybe I did not understand how it works.
Also: it's 2016. Why is this using PBKDF2? If PBKDF2 is what you've got and you're protecting a website, that's fine, but this is a password manager.
Is the "commercial" version of this also Ruby code wrapping OpenSSL?
It is not the algorithm only but if you can look a little bit more closely, it is iteration count too. It uses 1.000 times and 10.000 times more iterations respectively.
Plus, depending on complexity, character set range enlarges.
>> Why is this using PBKDF2?
We would like to use more industry-standart way of things rather than individual works.
>> Is the "commercial" version of this also Ruby code wrapping OpenSSL?
Commercial version is purely written C version of it and backed up with OpenSSL on some cases.
Why do simpler passwords get a different construction? What does password complexity have to do with KDF hardness?
Fortunately, Colin Percival came up with a much better solution in scrypt. It's a nice default if you want something battle-tested for a long time. Nobody should be using SHA-1, etc with solutions like scrypt available.
1. How hard it is for someone to steal them 2. How easy they are to retrieve when I need them
I'm currently really happy with 1Password on both counts, and I don't really understand why I should move. A competitor would need to establish that they are at least as secure as 1Password, and this landing page doesn't do that at all. For all I know, it's been built by a nefarious hacker or some junior Node.js developer who's just discovered security.
Has it been audited? What is the roadmap for the project? These things are much more important than some technical explanation that I didn't really understand.
Forgiva is actually big brother of kyle (https://github.com/esurharun/kyle) which has been at use for nearly 2 years and experienced and tested a lot.
Yes, you are definitely right on that we should put roadmap on webpage.
And no we are nor "nefarious" hackers neither junior NodeJS developers. :)
What does this even mean? Aren't they as safe as the cryptography being used (key derivation scheme, encryption method, etc.)?
(Of course, if a machine is compromised with a keylogger, it's pretty much game over anyway. Unless you use a hardware authentication token.)
Again "theoretically" all encryption methods prone to brute-force attacks. And plus, encrypted storages indirectly reveals "encryption passwords" on succeeded attacks.
ret += Constants::PASSWORD_CHARS[c % Constants::PASSWORD_CHARS.length]
Also, what is this? (From https://github.com/sceptive/Forgiva)
algorithm forgiva-iterative-hashing
Input: Value to hashed as DATA, Algorithm array AARRAY
Ouput: Hashed input data
final_value = DATA
for each character C in DATA
algorithm = AARRAY index of (C code num modulus AARRAY)
final_value = forgiva-hash(final_value, algorithm)
return final_value
> It's developed by security professionals
Every master-key generates a different time and processor cost as you see. So this makes estimations fail for all attacking sessions.
"Well respected, international company based on Istanbul which works only with underground talents.Hacks big corporations for good and creates trusted relationships and work hard to protect them against Sith Lords. Helps companies to strengthen their security layers and provides educational services."
Forgiva is based on the premise that a password generation scheme is more secure than a password database. I'm unconvinced in general; from what I see in the FAQ and the Ruby code on Github, even less so for this particular implementation. Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell.
Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2].
It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" risks. Think like you are investing your money? Would you prefer betting on just one thing or spreading it over various different investment opportunities?
[1] http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html [2] http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...
I would be nervous about taking password storage advice from someone who thinks bcrypt "got outdated and requires a better version".
We had a Password Hashing Competition because people realized that password hashing and KDFs had become an important topic that hadn't received significant formal study. Similarly: we're having a CAESAR competition because people have recognized the importance of all-in-one authenticated encryption constructions. The existence of CAESAR, AEZ, NORX, &c doesn't mean that Poly1305-AES is "outdated and requires a better version".
Sorry for misunderstanding.
If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs [1]? If so, why bother mentioning how long it would take on a CPU at all?
[1] http://arstechnica.com/security/2012/12/25-gpu-cluster-crack...
When you're dealing with time scales greater than a decade, probably not. The right answer is almost always to wait until future hardware is available that can crack the password significantly faster than our current CPUs and GPUs. Whether that's quantum computers or just faster iterations of the kind of stuff we've got now doesn't really matter...the time spent waiting for new hardware is insignificant compared to the time spent waiting for calculations on current hardware to complete.
But I agree that it's disingenuous to list numbers like that because they're meaningless and aren't at all the answer to the "How soon can my password be cracked?" question.
Modern multi-GPU instances are 560,000x faster, 350 billion guesses per second. So that gets you to 6 million years / 560,000 = ~100 years. So "decade" isn't accurate in this case, but only because of the awful comparison to begin with. Comparing a 2013 CPU to even a 2013 GPU will give you a 100 or 1000x bump easily, and since this is a case of "embarrassingly parallel" operation your scale is much smaller than expected.
Also note: 350 billion is for NTLM in 2012. I can't find equivalent stats for modern GPUs from a few minutes of searching on my phone, but I know they're a factor of 2-10x better, so 2^70 is easily within reach.
And its not just that, everything you use your passwords for these days, is stored on some sort of storage in a cloudy architecture. Scattered all over the world in thousands of datacenters. You probably are currently trusting thousands of people working over there, but you dont even know these guys. Terrible imho..
This solution does not store passwords at all, if I understand it correctly.
So whining about storing them on "someone else disk" is a bit odd, don't you think?
The alternative to trust a well - established company with your Tinder or gmail password is unthinkable.
And at the same time you may forget the options you used in Vault, it is not an option in Forgiva.
Is there any evidence that using multiple algorithms has any benefit over simply increasing the cost factor on one?
A( B( C(X) ) ), if A becomes broken in the future, its still
B( C(X) ), as opposed to just revealing X straight away
How does this handle changing passwords? How can I know from the master secret that xyz.com is on the 4th password?
You can specify password length if it gets too long and it's character set provides symbols, numbers and letters in it.
>> How does this handle changing passwords?
It has a renewal mechanism to switch to a new password.
>> How can I know from the master secret that xyz.com is on the 4th password?
Can you explain more about what you mean?
So then there has to be metadata to list the site domain, username, which generation of password, which characters are allowed or disallowed, length, KDF difficulty, etc? Where is that information stored?
What I'm getting at is with a brain wallet I only need to remember my secret and know the algorithm used to generate the key. With this it seems like you need a database to store more information, and without it, it's difficult to get your passwords back.
1) How is this safer than a standard password manager with TOTP-based 2FA? The second token, either produced by TOTP or something like a Yubikey, would guard against keyloggers, since the one-time code is useless after it has been entered.
2) How is the certificate generated, and what is it based on? Is the cert unique per device, or would I copy it to my other devices that need to access Forgiva ala a public key?
3) There are some typos and other grammatical weirdness on the page that suggests English is not the writer's first language. That's fine, but it looks unprofessional. I can make some proofreading suggestions if you feel inclined. I don't really believe in this product, but I'd prefer it to be judged on its technical integrity rather than the quality of its marketing, so I'd be happy to help polish it up.
No matter how many factors you are using, sooner-or-later you pass it with keyboards.And that step may be intercepted and you may think that you sent the second token to the other-side but failed.
I can provide you a special investigation of Sceptive to show how 2-factor-authentications has been bypassed by malwares targeting Eastern-Europe banks.
>> 2) How is the certificate generated, and what is it based on? Is the cert unique per device, or would I copy it to my other devices that need to access Forgiva ala a public key?
It is not unique per device. You can copy it to all devices you use no matter what.
>> 3) There are some typos and other grammatical weirdness on the page that suggests English is not the writer's first language. That's fine, but it looks unprofessional. I can make some proofreading suggestions if you feel inclined. I don't really believe in this product, but I'd prefer it to be judged on its technical integrity rather than the quality of its marketing, so I'd be happy to help polish it up.
It would be an excellent help, we are very unprofessional on language and marketing -as you well see-. Can you please send an e-mail to us at info@forgiva.com to tell us our mistakes?
It looks like they used SHA1 checks in the installer. I suspect the author doesn't realize that older Win installers that use SHA1 are blindly rejected by Win10 as a security measure (mostly because it's so feasible to game).
It is a very poor introduction to the application on the majority platform.
>> It is a very poor introduction to the application on the majority platform.
Yes you are right it can be better and will be.
Consider proof-reading the website: I wouldn't trust someone to do my crypto who can't spell the basics.
And planning to make it available as Telegram Bot.
> How about for sites with restrictive password requirements?
> Passwords, generated by Forgiva are offered with 16 characters minimum (you can go up to 32 characters by default) of length and 70 bits of entropy guaranteed on normal complexity level. And it is called on strong level for financial institutions and military grade applications.
> Thus it is not expected for any site to deny Forgiva generated passwords.
This seems naive, at best. If you can't store an eight character alphanumeric password, you're not usefully managing passwords.
Now what if this happens on a site where you can not reset passwords, such as blockchain.info, am I SOL?
I like storing passwords becuase I have 100% certainty that it won't just magically generate the wrong one.
Or as android app: https://play.google.com/store/apps/details?id=de.ninov.maste...
It works by using SHA256-HMAC on the service name with your master key as key and then encoding it in Base85 or Base62 (if you don't want special characters)
The encrypted password database is an advantage. You have to steal it to be able to even try cracking. If it's fully deterministic, anyone with any output can go nuts trying to crack the master password, and then get all other credentials.
> If you suspect against keyloggers or malware, Forgiva presents a visual confirmation ystem which leaves less hope for the attackers.
But maybe it's actually phishing?!?:
> And if you get registered, Forgiva uses your registration signature to generate special passwords for you. That means for a successful attack it will require keyboard and monitor access, plus a file system gain too.