Cool idea, but the main gripe I have with it is that the passwords it generates are clearly not made for remembering, but regenerating them takes multiple seconds.
>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?
Maybe the point is that you do not need to store the database securely, that you can store it openly, as long as the certificate used to generate the passwords is kept secret.
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.
The way I read it... it's a password manager that doesn't store passwords (centrally or locally).
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.
Except if the master db is stolen without the master password, one can throw guessed passwords at it and know when one worked (i.e. the db becomes readable).
I was planning to write one as I do not like existing ones but time is a slight issue: without versions for all platforms and some way to keep them in sync it is hard to switch...
And at the same time using various other methods "depending on the master key" makes it impossible for an accurate time and process estimation for brute-force attacks.
As an end user, I don't care about how the passwords are stored. I care mostly about two things:
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.
"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."
Again "theoretically" all encryption methods prone to brute-force attacks. And plus, encrypted storages indirectly reveals "encryption passwords" on succeeded attacks.
And if you go that path, "theoretically" an attacker might simply guess your password on the first try when attempting to log in as you, so password "storages" and "brute-force" has nothing to do it.
You are mistaken on one think: it is not just being it "theoretically" possible but likeliness -or hardness- of it.
If the possibility of an attacker guessing my password at first try is one in a billion -or trillion- chance, then we can say it pretty secure. But hacking a cloud with a possible zero-day flaw and cracking a password database is not that hard if we compare it with your example.
> all encryption methods prone to brute-force attacks
The chance of succeeding within our lifetime with a brute-force attack against modern encryption is far less than one in a trillion. So in your words, it is far better than "pretty secure".
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
Is that selection of algorithms based on the hash? Doesn’t seem to jive with
It generates underterministic way of calculation for a time-span of a successfull brute-force attack. Various hashing and encryption algorithms runs in different performance values. Thus, estimating for a CPU/GPU power or time range to attack Forgiva is more harder than other systems.
Every master-key generates a different time and processor cost as you see. So this makes estimations fail for all attacking sessions.
Your password will never be secure when you store it on someone else his disk or let someone else encrypt your password. Its not a matter of how, but when there will be a way to retreive those passwords by anything but you.
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..
In the overview, it says on cloud or local. Which made me think, why would you even suggest storing this on a cloudy device when your offering a password manager.
You are right. Only after having reviewed the code for the OS (and before that reverse - engineered the BIOS firmware), recompiled it yourself and then reviewed & recompiled keepass can you state that you are safe.
This is the recommended way to go for the standard user to have his passwords safely stored.
The alternative to trust a well - established company with your Tinder or gmail password is unthinkable.
> To crack a password with 70 bit entropy on a MacBook Pro Early 2013 it will take ~6 million years to complete all combinations on Normal complexity. On Intermediate complexity it will take ~24 million years and on Advanced complexity it will take ~280 million years to reach all combinations at minimum.
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?
It's just for giving an idea about hardness. Of course GPU(s) or/and parallel processing far more better than that. We will put results with clusters and GPUs soon.
> If you were cracking a password wouldn't it be significantly faster to use GPU(s) rather than CPUs?
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.
2^70 / 6,000,000 years / 365.25 days / 24 hours / 60 minutes / 60 seconds = 6.2 million reference guesses per second.
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.
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)
+1 for masterpassword. I always loved the concept of brain vaults. One thing about masterpassword is that I don't trust the clients and I can't inspect what's being logged when I fire up the app. The iOS app is closed source and proprietary and although the idea is great, the clients are not to be trusted. Get yourself a copy of the Javascript client, and place it in a secure VM so you have full oversight of what the code is doing. And don't let the application talk to the internet...
As I see it, the main benefit of deterministic password generation is the convenience of not needing a password database. Indeed, if the scheme is simple and/or portable enough (e.g., PBKDF2) you can implement it from scratch in a minute or two, depending on what software you have handy. The convenience breaks down as you need to maintain additional state: password rotation, site-specific password rules, etc.
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.
>> 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?
Not only did that not happen to bcrypt, but the whole point of bcrypt is that that doesn't happen: it's an adaptive hashing scheme, which means it comes with a dial you can turn to up the hardness as computers get faster.
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".
Probably i should explain what i meant with "got outdated and requires a better version" sentence. It is a race and as stronger algorithms comes to life -and stronger attack methods invented against them-, others gets simply weaker and weaker just like happened to MD2 and then MD4 And then MD5.
MD4 and MD5 didn't get easier and easier to crack due to cryptanalytic advances; it got easier to generate collisions. That's a serious problem for a cryptographic hash, but depending on the construction you're using, it might not have anything to do with MD5's suitability as a password hash. There's no password hash cracking tool I'm aware of that takes advantage of MD5's weaknesses.
What evidence do you have that your scheme is any more future proof than, say, Argon2? No, just using a bunch of different primitives is not going to guard against the kind of breaks found in bcrypt or scrypt, which aren't really breaks at all.
Forgiva is not a key-derivation algorithm itself to compare with Argon2 but a combination way for various hashing and encryption algorithms along PBKDF2 "depending on master-key". So it's as much future-proof as master-key generated algorithm sequence.
And in this case which methods would you offer and prefer for future-proofing with comparison to other KDFs?
A couple thoughts that came to mind as I was reading it:
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.
>> 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.
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?
The Windows 64-bit installer is giving a bad signature even though its SHA256 installer hash appears to be correct.
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.
Actually installer compiled using Visual Studio 2015 on Windows 10 platform. Nothing specifically edited to the way of SHA1 but we fix it on next release.
>> It is a very poor introduction to the application on the majority platform.
I'm reading the open source code and this thing is... odd. For instance: it has a "simple", "intermediate", and "advanced" password complexity, and depending on which you choose, it uses SHA1, SHA2-256, and SHA2-512 for the PBKDF2 hash. What does password complexity have to do with the strength of the algorithm used to generate passwords?
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?
I argued with that since cryptographers first told me about it. Ludicrous concept. The goal is to eliminate brute force attacks by making the process inherently slow. That technique starts with something inherently ultra-fast that everyone is trying to speed up and hardware accelerate then iterates it a bit. Better concept to get a slow process is design an algorithm that is inherently slow and hard to speed up, esp requiring many memory accesses. My hack, aimed at defeating FPGA's, was putting a random stream into no less than 16MB of RAM (SRAM limit at time) that I iterated through randomly with a hash function. All inherently sequential, random, and large. Accelerate that!
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.
Just pick a real password hash and dial up the hardness as high as you reasonably can for your environment. Don't do anything more complicated than that.
>> What does password complexity have to do with the strength of the algorithm used to generate passwords?
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.
It's probably because different understanding of same terms. With "complexity" word we mean hardness to generate. It doesnt adds up more algorithms but character sets and hashing algorithms for PBKDF2 respectively.
Why, exactly, would a user ever want to generate a password with a weaker KDF?
A password with lower levels of string complexity might make sense --- 1Password's strong passwords can sometimes be rejected by crappy websites. A password that sacrifices cryptographic strength in order to save a few tens of milliseconds of KDF, though, makes no sense at all.
I want a password manager with Argon2 configured to take 10 seconds and 1GB of RAM, playing a gratuitous 3D animation of a vault slowly opening alongside CPU and bandwidth utilization graphs.
Or if your attack model allows that reading protected files off a user's device is less likely than the cloud-synced database being compromised, you might derive the master encryption key as KDF_fast(KDF_slow(password)+password)), where KDF_slow takes 5 minutes and is stored on disk, but KDF_cheap takes 5 seconds.
How does this handle situations where the generated password isn't accepted by the site? eg. Is too long, absolutely must have at least one symbol and one number, etc.
How does this handle changing passwords? How can I know from the master secret that xyz.com is on the 4th password?
>> How does this handle situations where the generated password isn't accepted by the site? eg. Is too long, absolutely must have at least one symbol and one number, etc.
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?
Okay, so the password generation is deterministic, based on a single secret I need to remember right?
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.
At first I wondered if it was a spoof. However, it could be incorrect grammar:
> 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.
> 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.
97 comments
[ 0.39 ms ] story [ 188 ms ] threadFixes poor passwords, accessibility and storage problems with highly secure way.
What does that even mean?
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.
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 long does the retrieval of a password take? Sub-second? 10 seconds?
How does it deal with stupid password format restrictions?
so, either password database + master password gets stolen, or salt database + master password gets stolen
Throwing passwords at a salt db gets you... what?
http://www.opensource.org/docs/osd
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
And at the same time using various other methods "depending on the master key" makes it impossible for an accurate time and process estimation for brute-force attacks.
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.
"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 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.
If the possibility of an attacker guessing my password at first try is one in a billion -or trillion- chance, then we can say it pretty secure. But hacking a cloud with a possible zero-day flaw and cracking a password database is not that hard if we compare it with your example.
> all encryption methods prone to brute-force attacks
The chance of succeeding within our lifetime with a brute-force attack against modern encryption is far less than one in a trillion. So in your words, it is far better than "pretty secure".
Also, what is this? (From https://github.com/sceptive/Forgiva)
Is that selection of algorithms based on the hash? Doesn’t seem to jive with> 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.
This is generally a bad thing and sounds like it will open you up to some kind of timing attack in the future.
> It generates underterministic way of calculation for a time-span of a successfull brute-force attack.
This doesn’t improve security and just adds unnecessary complexity.
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?
Where? I don't see "cloud" anywhere on that page..?
Some people value usability over absolute security.
The alternative to trust a well - established company with your Tinder or gmail password is unthinkable.
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.
And planning to make it available as Telegram Bot.
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.
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)
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.
So, no: this isn't happening with bcrypt.
And in this case which methods would you offer and prefer for future-proofing with comparison to other KDFs?
But regarding criticizes probably there will be bcrypt, scrypt and argon2 implementations as options on the next release.
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.
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?
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.
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?
A password with lower levels of string complexity might make sense --- 1Password's strong passwords can sometimes be rejected by crappy websites. A password that sacrifices cryptographic strength in order to save a few tens of milliseconds of KDF, though, makes no sense at all.
Also: really, you should not be using PBKDF2.
Or if your attack model allows that reading protected files off a user's device is less likely than the cloud-synced database being compromised, you might derive the master encryption key as KDF_fast(KDF_slow(password)+password)), where KDF_slow takes 5 minutes and is stored on disk, but KDF_cheap takes 5 seconds.
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.
Consider proof-reading the website: I wouldn't trust someone to do my crypto who can't spell the basics.
> 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.
> 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.